Request for feedback: Reorganizing BIDS website

The BIDS Steering Group has raised a request for feedback on reorganizing the bids website. The source code for the website is hosted on GitHub.

The idea is: break out the tabs into individual pages rather than one long page. In addition to converting the source code from html to md (or rst). RST will give more flexibility to theming

2 Likes

Personally, I don’t see a problem with the page being “a single long page”, because I feel like this is more of a “style” question than a usability question.

–> In practice, a user always has the navigation bar at the top of the page and can use the links to navigate the single page AS IF it were separate pages.

Regarding going from html to RST: RST will not provide more flexibility than HTML, but it might allow maintainers to more easily make changes and adjustments … without having to know a lot of HTML+CSS.

I am generally favorable towards having the website in RST instead of pure HTML+CSS. However, such a change would be worth it only if we are about to change several things about the website. The change would not be worth it by itself, I think.

1 Like

Focusing on the issue of usability, rather than maintenance –

I tend to agree with @sappelhoff that long pages vs tabs is mostly a matter of style, but I do think there can be a usability angle if the page is too long. For example, we could have sub-menus under “Getting Started” pointing to each of the relevant sections (eg, the BIDS Starter Kit) which would make them easier to access. I have no real insight, though, if they’re being missed right now.

Is there anyone in our community with experience in designing Website usability surveys ? This would also be a great chance to improve a11y compliance.

Also, I pinged this on twitter and got some great feedback from Chris Holdgraf: https://twitter.com/choldgraf/status/1198737491508940800?s=20

1 Like

The consideration that triggered the idea for separate pages versus the current single long one is that we see the tendency to add documentation to the read the docs page (with clear hierarchical structure) rather than to the main website. Examples are the starter kit (already there) and the governance document see here, Furthermore, there are documents/pages such as bids apps and various google docs which now live in their own ecosystem that probably would be better exposed when integrated in the home page.

So perhaps to rephrase: if we were to add more information to the bids “home” page than it currently contains, how would we want to structure that information, and how would we want to make it editable?

1 Like

Thanks for the clarification @robert

If we can revamp the website to be the anchor that it should be, it would allow us to keep the specification (=read the docs page) clean and a specification only, without becoming the website-replacement. With this background, I would be supportive of adopting a “several pages” format and changing to sphinx/RST = something that can easily be edited frequently by non-pro-webdesigners.

@effigies @franklin and I had many discussions in the past about what to include on the specification page and what not to include there. So it’d be good to hear their opinions.

that’s just a feature I’d like to see somewhere – tagging companies who are doing some BIDS (at least 4 for EEG as far as I know)

with @robert’s framing of the question I think the multiple pages approach will allow us to more strongly organize our information into groups and those groups can become our tabs. If one is looking for something specific they can be pointed directly to that page url without going through the entire site page. This will also keep the RTD specification clean with only specification information and revamp the website so that can be more of our central place (it will also help with some of our GitHub usability issues brought up before too)

An added benefit of doing the multiple pages is that I think it allows for more sustainable scaling with ease of use in mind.

Regarding converting to RST - that sounds good it will allow for more contributors on the website. Though what may we lose by moving over to RST from HTML? Perhaps flexibility in design?

I find it hard to find things on the BIDS site. I would recommend getting rid of the big brain graphic and focus on what people want to know. (I also don’t much like the black background — seems very grim.)

  1. What is BIDS… BTW – saying BIDS is a simple way to organize data is not accurate. It is a pain to follow all of the naming schemes etc (speaking from experience). The whole thing that shows an example of a dataset mapping on the first page is really in the weeds and should be somewhere else. A more accurate thing would be to say that it is a standardized way to organize your data that is supported several sites for data sharing (e.g. such as openNeuro) and that by putting it in to standard form it is more likely to be used by others.

  2. I am not sure what the status is of various tools/platforms for support of BIDS. My impression is that there are commitments from several major platforms to support BIDS in the future, but I am unclear about what kind of tool support is actually there. It would be nice to clarify that if there is tool support.

  3. Clicking on take a look at how the community uses BIDS seems to direct me to a user survey.

Just one more thing ---- the whole page is way too spread out with very little information conveyed for the space occupied. Everything that is currently conveyed on the landing page for BIDS could be easily fit in one screen’s worth (Except maybe the example of the directory structure.)

Hi! This is my first time in neurostars! Happy to have joined in one app more :slight_smile:
There are so many useful tools that are used in the BIDS community that sometimes we may be a bit overwhelmed and lost. So does this replace the mailing list for discussions?

I agree with most of what has been said regarding the web page.

I will also vote to restructure the webpage. We should be straight and simple about what’s BIDS and have the different sections clearly differentiated. So people could easily find what they need.

I’m not an expert on web design, but I’ll make some suggestions in case they can be useful:

– Put logo on the header and remove all the other images

– I would prefer to remove black background

– I’ll keep (for now) the following main tabs or equivalent:

  1. HOME
  2. About BIDS (history, etc)
  3. BIDS specification (also links to the extensions, etc)
  4. Collaborate (can include getting started, getting involved, etc)
  5. Tools (software, etc)
  6. News (blog, mailing list, neurostars, github, etc)
  7. Funding
  8. Contact

– All the other info could be reorganized inside these.

– If possible use a readable letter font, avoid excessive text and use representative icons for the sections so everything becomes less dense and more visual.

– If I have time in the coming weeks I’ll prepare a figure that could replace the current ones, for BIDS at a glance.

– I’m also fond of short video tutorials 1-2min, about usability of the different tools and concepts, we can also think about this for the future

I think we could merge the web content, with the centralized document: https://docs.google.com/document/d/1u680oW6ktEXKyE6_V3kcdZAZ5Ma445ZwG9_oBuE7z1A/edit
(if it’s not already done)

So we can have a global perspective of all the info we have, and we are able to design the web content accordingly.

I like the revision… I was never a fan of the one-big-page, and I think the new draft looks great.

Hi everyone! I’ve just approved @robert’s PR: https://github.com/bids-standard/bids-website/pull/56.

You can see an example of the website at https://robertoostenveld.github.io/bids-website/get_involved

So I guess this is a “speak now” kinda moment for the single page vs multiple page question. (My positive review should be taken that I also prefer the multi-page layout).

Everything else could be turned into an issue at the GitHub repository for discussion and (hopefully) pull requests to update!