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@xxxxxxxxx http://n-man.com/ LinkedIn: http://linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ --
Attachment:
pgpsKwDrwlsY1.pgp
Description: PGP signature
