Tweaking the design of the wiki

[Patrick W. Barnes]

On Tuesday 28 November 2006 19:58, Dimitris Glezos wrote:
> O/H Patrick W. Barnes έγραψε:
>
> > My one suggestion would be to keep the original default font size.  I've
> > not heard any complaints about the font size in the past, and increasing
> > it could break some of the less-proper design elements used in the wiki
> > and wouldn't allow as much information to fit on any given screen.
>
> The font size is very small and should be increased, this is the conscious
> I got from some people. Even if it means we will have less content on a
> page.
>
> The content on the page is already more than what it should be: the
> paragraphs are very wide in high resolutions and the text is very small
> (there is a certain ratio of letters per row that makes a paragraph more
> readable but even the newer font size exceeds that).

Don't design to high resolutions.

Design pages that are as generic as possible, but where something must be 
specific to a resolution, stick to the range where the majority sits: 800x600 
to 1024x768.  It may seem callous, but it's not a web designer's job to 
accommodate people that use high resolutions beyond their eyesight without 
properly configuring their systems, especially to the detriment of the 
majority of viewers.  I personally use 1920x1440 on my primary workstation, 
and I find the current appearance of the wiki to be about perfect, without 
any zoom or configuration changes, and it still looks great on my 1024x768 
laptop.  Since I'm nearly blind, I have to wonder what other people are 
seeing that is causing them to complain.  I know that the static "*em" size 
attributes are interpreted differently by different systems and browsers, as 
are most sizing specifications, but I guess I haven't seen the full extent of 
the differences.  I'm not saying we can't adjust the CSS to increase the font 
size a little, but be careful about what you're targetting.

As for "letters per row", that's really not something we can or should attempt 
to plan for in HTML/CSS design.  It is beyond the scope of markup and totally 
irrelevant for dynamically sized elements.

>
> Although we should really use something close to 1em and let the user
> choose the zooming, the current proposal (0.85em) is relatively small to
> fit a lot of text in the page. For reference, one could check out the
> mozilla, gnome and ubuntu wikis.
>

> >
> > Something else to be aware of is that we still plan on upgrading the wiki
> > soon, which would mean forward-porting theme changes.  It might be easier
> > to wait until after the upgrade to apply changes.
>
> When is the update scheduled? If we do need to tweak the code to make the
> wiki more usable, we should. Of course, we should do it in a way that we
> can apply it for every update.

It is actively being worked on right now.  A test site is already up and 
running, and it won't take long for the team that's handling it to work out 
the last few problems.

>
> We might need some more changes, like putting a <div> around the table of
> contents to manipulate it through CSS.
>

That would require patching the MoinMoin core.  Changes like that should be 
submitted upstream and given a chance to filter down, because we really don't 
want to commit to that sort of maintenance.

-- 
Patrick "The N-Man" Barnes
nman64 at n-man.com

http://n-man.com/

LinkedIn:
http://linkedin.com/in/nman64

Have I been helpful?  Rate my assistance!
http://rate.affero.net/nman64/
-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/websites/attachments/20061129/208bf500/attachment.sig>