short and detailed buttons in the wiki, html help wanted

Website
21

Okay please try implementing your suggestion.

22

Almost done, but needs some more styling, especially when JS is disabled to distinguish both versions (suggestions for that part are welcome).
With JS: http://jsfiddle.net/vatvch5a/3/ (updated in edit)
Without JS: http://jsfiddle.net/dscy2u9r/2/ (updated in edit)

It supports deep links (e.g. http://example.com/site#fragment ) and I used the bootstrap buttons to match the current skin.

Is something like this ok?

{{sd-start-short}}
short text
{{sd-end-short-start-detailed}}
some more text
{{sd-end-detailed}}

(would be 3 widgets and could mess up the site (i.e. break the HTML) if not used correctly, but the alternative would be something like {{sd|short=some text|detailed=some more text}} and I’m not sure if that would support more than just plain text)

1 Like
23

Looks awesome!

Lets say a user overlooked something in the short version and asks in the forums… In such a case, could we answer by replying with a link to a specific section in the detailed section?

I guess so. Actually, better than expected.

Yes, however I am not concerned about breaking the html. (As long as the wiki edit button is still functional but even if it was not, the link for editing can be guessed.)

And the version also easily breaks on markup errors, so no advantages. Actually that version would complicate things. Rather than “some text” we may have to use a wiki template.

So your proposal from your last post at the top sounds best.

24

That’s what I meant by:

The link at the top on http://jsfiddle.net/vatvch5a/3/ is an example for this

1 Like
25

Awesome!

Is it possible for the text “go to jum target in detailed section” to be hidden if javascript is available? (Because in these cases it is superfluous.)

26

The link is not part of the widget, just an example for a Link that points into the detailed section.

1 Like
27

I split the code again in multiple files: http://www.xup.in/dl,88937037/sd.zip/ installation procedure is the same as for ⚓ T420 CodeSelect template / widget unusably slow on big pages

28

Done with applying this:

Test page:
https://www.whonix.org/wiki/T1

Thank you very much for your contributions! Very good impression at first sight. Might require some minor fine tuning for the javascript free version. I will be modifying an actual wiki page, create a short version and move the existing to the long version.

Edit:
Updated links.

1 Like
29

I just noticed I forgot to remove a debugging line in https://www.whonix.org/wiki/MediaWiki:Common.js: console.log(offset);.

Edit:
Also fixed a minor bug http://www.xup.in/dl,79471254/sd.js/ (missing check if an a-element has a href-tag)

30

Removed console.log(offset);.

Also applied.

31

Using the brand new short / detailed buttons on one wiki page now so we can have a look how it actually looks. I appreciated some feedback! Let’s gather some feedback in this small group first before I blog about this and perhaps gather more feedback. Example page:

Control and Monitor Tor

My feedback…

javascript enabled version:

  • Short version looks really good.

  • The links to the detailed version are functional.

  • The detailed version suffers from some strangeness. The table of contents (TOC) contains the chapters Tor Controller and Arm. These links are functional. But once the user scrolls down, these topics do not appear. This is because they are part of the short version. The first chapter is tor-ctrlthat could be confusing.

  • I guess someone being provided the choice short / detailed and clicking quickly on detailed… This is what I expect… Would be confused. I guess someone clicking detailed would expect the detailed version to include the “short” information also.

  • Perhaps our recommendation, and standard sentence for the detailed version should be “do not skip the short version”? Does that seem feasible? (We cannot bend users expectations and behaviors much.)

  • What could we do about this? Duplicate the “short” information? [1] Would be doable using wiki templates. And therefore take some seo degradation for the duplicate text that search engines would see.

javascript disabled version:

  • Looks coherent.
  • If we did [1] we would kinda mess it up, I guess.

Any thoughts?

32

How about moving the TOC out of the detailed section and structure it like this:

  • Short
  • Arm
    • Arm usage
    • Arm FAQ
  • Detailed
  • tor-ctrl
    • On Whonix-Gateway
    • On Whonix-Workstation
      • Example: Get a New Identity using Whonix-Workstation Terminal
  • tor-prompt
  • netcat
  • Vidalia
  • Footnotes
  • License

That’s because of the wording. I would also expect that “detailed” shows me the same content but more detailed (i.e. more reasons, explanations, examples, etc.) than the short version. Maybe something like “recommended” / “alternatives (advanced)” would be better in this case?

Before we duplicate the content via template: modifying the CSS to display the short version every time would be the better solution, also works if JS is disabled.

33

Good day,

Just wanted to say that when using mobile devices, this soultion appears to not work at the moment.
Have a nice day,

Ego

1 Like
34

If I run the site on an emulated mobile device I get the error Unknown dependency: mediawiki.legacy.wikibits, which is a MediaWiki issue and should be resolved in ⚓ T108191 Mobile site not functional - Uncaught Error: Unknown dependency: mediawiki.legacy.wikibits

Edit:
Change that should fix it: rMWc588b36cdbb4

1 Like
35

Just now updated mediawiki extension MobileFrontend. Has the Unknown dependency: mediawiki.legacy.wikibits error been fixed?

Now also added here:

Mobile version still does not work. Any idea?

36

I still get the same Unknown dependency: mediawiki.legacy.wikibits error

37

How can I reproduce this?

38

You can simulate a device in chrome(ium) as explained here: Chrome DevTools - Chrome Developers (edit: you have to reload the page after enabling it)

The error message shows up in the Console tab.

39

Confirmed. I can see this error in console.

Looks like our mediawiki version 1.26.3 does include this fix already.

See:
https://github.com/Whonix/www/blob/master/w/resources/Resources.php#L1872-L1879

So this is perhaps a different bug that requires a different fix?

(Updating mediawiki extension MobileFrontend was not strictly required but good that I did that anyhow. Unrelated.)

40

I really like to avoid this very much since that would defeat the purpose the the short version which has the goal of not intimidating the user. The short version most of the time (not always) should not include a TOC. Should be as short and simple looking as possible. A long TOC gets into the way.

In the case of the Tor Controller wiki page that would work, I guess.

Yes, perhaps the whole design idea behind short / detailed can be revisited. recommended / alternatives could be another another way to design this. Perhaps lets discuss this using example wiki pages.

Perhaps we end up making the button labels short / detailed vs recommended / alternatives vs other words configurable using the wiki templates. If that would be possible at all? Too early to say if that is a useful option.

Original short / detailed buttons idea:

  • Short version should just contain one option. As simple as possible. No footnotes.
  • Detailed version should contain the short version. Since it would contain footnotes, it would have to include a modified copy of the short version plus all other alternatives and reasoning.

New recommended / alternatives buttons idea:

  • All users are expected to read the recommended version. (Which then would have to include footnotes.)
  • Users who want more, and reasoning. would additionally check out the detailed version.

Or button labels: essential / alternatives?

Possible example wiki pages where we can consider this: