-
Fedora websites look-n-feel: Mirror manager
-
Lately a lot of work has been done on increasing the usability of the Fedora websites — I’ve blogged about some of our efforts concerning the wiki in the past [1], [2]. We’ve been using web apps more and more to capture information and knowledge, and to provide functionality to developers and users. A bunch of great web-based infrastructure tools were written from various Fedora code monkeys that handle account administrative tasks, package building and updating, knowledge sharing, mirrors management, and translation coordination. Basically, we are on tools building spree!
So, when designing the template of fedoraproject.org and the content style of translate.fpo, we kept in mind that a common look-n-feel between all our web resources would be desirable for everyone: having a consistent, usable, high-quality web look-n-feel across the project is a good thing™. The idea is that all Fedora websites and web apps “feel” the same, even if they use completely different technologies underneath.
Take our mirror manager for example. Here’s a small patchset to the templates that landed the other day, wrapping the content in the header-n-footer theme of fedoraproject.org.
It basically inherits from the general fedoraproject.org template, but having smaller text to convey lots of information compared to the marketing-oriented big text of the main page. Using icons to quickly capture information is often used and people like it because they can identify the resource more quickly, navigate more intuitively, and get less often disoriented in a web resource.
The old design could need some love, and Matt Domsch (the mirror wrangler) gladly accepted tweaks to the way we organize information on the page. Here’s how a table on the public mirror list looked like before:
It’s a filter for the giant mirror list we have. Since it’s not main content, it’s probably better if it didn’t take a big space from the width of a 1024-width page. Also, incremental tables usually span downwards (in rows), mainly because we’re used in vertical scrolling instead of horizontal. Finally, the table borders aren’t really important to spend so many (valuable) black pixels there, and so are the underlines.
On the right is how the new filter looks like. Having the table slim and floating on the right of the page, the user can follow the content first and then catch the filter only if they need to do so. A caption at the top makes sure that even a cropped screenshot like this one makes sense to everyone, and the alternate row colors work better for separating rows, since lines increase contrast in places that are not readable, which reduces the accessibility of the information (in this case, the text itself).
These small details play an important role in helping users find what the want more easily, and spend more time on our website. Feeling good when browsing is an often neglected, but astonishingly vital part of being productive and efficient, both as an information provider but also as an information consumer.
At some point, we could separate the basic templating styles from the app-specific ones, so that each app can choose what to override and what common style/element to leave in peace. Common templates in kid, genshi or any other templating language will be packaged in a common RPM, which will be required from our web apps, and
yum install foowill simply require, say,fedora-websites-common. This way, each web server can have the set of themes and styles locally with no need to worry that when one web server fails some other website will look weird, and also updating all our websites for a common element (eg. our footer text) could be as easy as pushing an update of the RPM package. -
μες τη νύχτα, Πέμπτη 6 Σεπτεμβρίου 2007
[ Fedora ] |
Σύνδεσμος
| Σχολιάστε!
I wonder, would it make more sense to list releases in decreasing rather increasing order? It seems folks might be more interested in the most recent releases than the older ones.
Actually even better might be to only list the currently-supported releases and hide the older ones behind an ‘archive’ link…
EPEL maybe should not be as prominent either?
Just some ideas!
Good ideas Máirín! :)
Thought of having EPEL as well, but there’s only so much one can (should) do in the template, really. The “archive” link is a must, and sounds like something that should probably be done with Javascript with no call to the server.
BTW, anyone who’d like to hack something, two related files are publiclist.kid and its controller, mirrorlist.py.
Dimitris,
This is a great idea and probably a little overdue. It probably doesn’t get said enough, but you do such amazing work for the Websites team, L10N, Docs, and others. Thanks for making so many improvements over the last year or so!
This stuff looks absolutely great. Thanks for the work you’ve done with all of this stuff.