Skip to content

New concept for platform-specific instructions #474

Closed

Description

@WasabiFan

Now that most of the site has been updated and streamlined, I'd like to take a look at optimizing the platform selection. This is the main sore point for me that makes a user's experience getting started seem non-polished or confusing, so I'm hoping that we can considerably improve it. There are a few parts to this, so see below.

Improve code which populates tabs

We currently have a fairly large code file that takes the HTML that is generated from markdown and converts it to well-formatted tabs with navigation. It also attempts to auto-detect the user's platform and choose that tab by default. While we currently supply a name in the markown that is then used as both the title and the user agent lookup, I'd like to separate the two actions so that we supply a technical name (osx, windows, etc) and it does a lookup to find both the proper text to display and the proper action to take to check the user agent. This means that we can change the titles without changing the markdown and can decouple platform detection from the titles.

Replace traditional tabs with page-level selector

We currently use a tab control to allow the user to select the platform that they want to use. This takes space on the sides, top and bottom and feels more like a "localized option" instead of a "global option". It also means that we have a tab control within the tab control to have different instructions for different versions of the OS (that's where we start losing some considerable space). I want to modify the JS to generate a page-level nav element (shown below), to make it less disruptive lower down on the page. This is what many developer-focused sites do (such as Microsoft's MSDN), and it works pretty well.

Here's a rough screenshot (obviously some styles are messed up in this test):
new platform selection idea

It'll need a border and a few other bits, but the majority of the styles are supplied by Bootstrap and the code is mostly already there.

Generate valid HTML

The script currently stores data in HTML by adding non-standard attributes to the elements (e.g. <li tab="Windows">). This is technically invalid HTML, as tab isn't an HTML attribute. I plan to change this to use data-* attributes and jQuery's .data(...) utility method to conform to HTML standards,


So, what do you think? Obviously these aren't the biggest changes, but It's always a win to increase usability and maintainability. I figure if I have the hour or two it'll take available I might as well get this fixed.

Activity

  1. dlech commented on Dec 28, 2015

    @dlech
    Member

    How do you handle nested tabs? For example we have different instructions for Windows 7/8/10 in some places.

    Also, what about the different robot platforms, EV3, BrickPi, PiStorms, EVB? It would be nice to have platform specific bits for these as well.

  2. WasabiFan commented on Dec 28, 2015

    @WasabiFan
    MemberAuthor

    How do you handle nested tabs? For example we have different instructions for Windows 7/8/10 in some places.

    Whoops, forgot to mention that! I can add dropdowns to platform items, so my plan is to show multiple versions as drop-down items on each "pill", as Bootstrap calls it.

    Also, what about the different robot platforms, EV3, BrickPi, PiStorms, EVB? It would be nice to have platform specific bits for these as well.

    That is also doable! My goal is to make that code as extensible as possible, so hopefully we can use it for any version or platform options. It might be best to, instead of putting the pills directly in the header, add a "platforms" option to that expands with a fly-out with the platform options in it. But that might be less obvious, so I'm open to ideas on how to make it clear that there are platform options if we need multiple.

    I hope to minimize conflicts, but it could end up that I just have to reimplement others' changes on top of mine.

  3. dlech commented on Sep 5, 2017

    @dlech
    Member

    I'm currently leaning towards moving most of the detailed documentation to readthedocs.org, mostly because of the support for versioned docs.

  4. dlech commented on Oct 28, 2017

    @dlech
    Member

    Going to go ahead and close this one since docs are moving to readthedocs/sphinx format. We can open a new issue for creating a sphinx extension for this sort of thing if we think we still need it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions