#196 #194 Redesign Docs front page layout- Navigation - Information Architecture
Opened by advika. Modified
fedora-docs/ advika/docs-fp-o prod  into  master

Download 196.patch

While going through user tests and interviews about the fedora docs website. One of the main complaints of the users was that :-
1) Lack of hierarchy :- The users couldn’t understand which topic contained which information. They couldn't navigate through the website.
2) Information was scattered :- The information displayed was not structured and “all over the place”
3) Too Much information :- The users complained that there was too much information and they didn’t understand where to look for what. They had to scan and search for everything which was tedious and time taking, after a few seconds they didn’t feel like completing tasks given to them while user testing.

To tackle these issues , I got to focusing on organizing, structuring, and labeling content in an effective and sustainable way. The goal is to help users find information and complete tasks. To do this, I needed to understand how the pieces fit together to create the larger picture, how items relate to each other within the system. To do that I got to reading all the available topics on the Fedora Docs Website. After a long time of reading I finally created an Information Architecture. The aim of Information Architecture is to describe the flow to the website, under which heading one would find a topic. It shows that in order to reach a specific topic, how the user would need to navigate through the website.

Link to the Information Architecture :- https://miro.com/app/board/o9J_lkoizq8=/?moveToWidget=3458764522412264047&cot=14

Currently the website contains 3 major heading :-
1. Edit this Page
2. User documentation
3. Projects and Community

There were 20 subheadings also on the front Page of the Fedora Docs front page.

I have converted and narrowed it down this to 5 Headings Displayed on the front page :-
1. Introduction
2. User Documentation
3. Community
4. Contribute
5. Guidelines
The users would then need to click these 5 major headings, through which they would access subsequent subheadings (These would not be displayed by default, Please also refer to the Information Architecture). These decisions were made to keep the navigation of the website easier and user friendly. It was also made to make the website more structured and hierarchal.

While this is to the best of my understanding of topics, I would love to gather more views on this Information Architecture, regarding the flow of information, terminologies used etc. To do that, I ask you to comment your views while I run to gather the users perspective on the information Architecture. After this the plan is to redesign the website following the Information Architecture.

The information architecture looks generally accurate. I don't think the first level under "User Documentation" is correct, though. The with the exception of EPEL, all of the entries there are operating systems. I admit, the terminology is pretty confusing to newcomers (and to experienced people as well), so you might want to review the Discussion thread where I tried to explain it.

What do you see as the distinction between "Community" and "Contribute"?

I'm not sure Guidelines needs to be a separate thing. That's essentially documentation for a particular kind of contributor (package maintainer), although I'd be open to the idea of a category that makes it easy to find various policies across the different sets of documentation.

The information architecture looks generally accurate. I don't think the first level under "User Documentation" is correct, though. The with the exception of EPEL, all of the entries there are operating systems. I admit, the terminology is pretty confusing to newcomers (and to experienced people as well), so you might want to review the Discussion thread where I tried to explain it.

What do you see as the distinction between "Community" and "Contribute"?

I'm not sure Guidelines needs to be a separate thing. That's essentially documentation for a particular kind of contributor (package maintainer), although I'd be open to the idea of a category that makes it easy to find various policies across the different sets of documentation.

You are right, after reading the discussion thread, it has become clear. I agree , someone coming to the website for the first time would be confused. The idea of the information architecture was to dive the information so that the user doesn't get overwhelmed by so many options. Perhaps we need to change the terminologies itself, in order to ensure better understanding and better navigation. Maybe we keep operating systems as a main heading and create sections under it to divide the information.

Coming to community and contribute . By Community, I want to distinct the role of different groups and teams fedora has. Now if anyone wants to contribute to these teams , there would be a separate option for them. However, going by the flow of information, A user should know about the team before contributing to it, hence the that option to contribute to a specific team would be available in the secondary layout and not on the front page. This can be covered in user testing and more perspectives should help solve this issue>

Lastly, Guidelines, The only reason I separated the guidelines was because they seemed important and because of a term in design called speculative design. It means that even though there is only one guidelines right now, assuming that Fedora will release more products and hence more guidelines will come , which might make the layout chaotic in the future even if it works right now. Hence I wanted to introduce a different category itself.

Metadata