[mythtv] Official Thread: Mythtv.org Redesign

Jean-Philippe Steinmetz caskater47 at gmail.com
Mon May 14 17:37:33 UTC 2007


>
> This is probably the main reason I don't like any of the oswd designs.
>
> While I don't think that all of the submitted designs are "corporate", I
> do agree that there is a heavy dose of bloggishness about them, which I
> know isn't right for MythTV.


Bloggishness is probably a better word for what I was thinking of but yes, I
think we agree on this point.


While I agree with some of your breakdowns, there are certain keywords
> that I personally find myself often using when poking around on open
> source project websites, and being that MythTV is targed at people like
> myself, I'm going to temporarily ignore the "you are not the user"
> mantra I often try to live by.  In no particular order:
>
> * Bugs
> * Screenshots
> * Download
>
> Your design does well with the download link, but at least some small
> homage should be paid to bug reports and screenshots.  Personally, I
> don't mind hiding screenshots on an "about" page and bugs under
> "support", but the keywords should be there somewhere.
>
> It also makes a fair amount of sense to keep both "bugs" and "wiki" as
> high-level "topics" because they're completely different sites and will
> need some kind of breadcrumb identification to show the user where
> he/she has browsed to.  We can't alienate the existing tech-oriented
> user base by hiding features that many of them find useful.  However, I
> will agree that Pidgin has handled this pretty well by putting all of
> the support links on their trac server.  We could do something similar
> for MythTV.
>
> -Chris
>
>
My other thought to this was having Support and Developer as separate menu
items. Support could house the wiki, forums, documentation and developer
could be a single page that houses all the related trac, svn, mailing list,
bugs, etc. pages similar to pidgin. That kind of separation on pidgin is
very clean. Screenshots as a main item would be fine, i'd even say maybe a
requirements page would be ok as well but studies of my own and those i've
read show that its much better to have fewer menu items and break things
down into subsequent pages than it is to lay it all out on the top level.
This is why I suggested the first structure ideas. Obviously theres plenty
of room left on the top menu bar for more items.

Jean-Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20070514/ea769946/attachment.htm 


More information about the mythtv-dev mailing list