7:45 p.m.
(CCing art-list)
Hi all.
I've made some CSS/foo for the wiki. Here are some screenshots:
http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning
There have been some comments for improving the design of the wiki in the past
[1] but unfortunately they went uncommitted. It is sad to see contributions and
ideas not receiving the attention they require.
The design of the wiki is a *major* marketing issue and the artwork team should
have the opportunity to tune and increase the wiki's usability. It would be
great if *tomorrow* we could make the website more usable and accessible,
wouldn't it? :)
It is a good idea (tm) to always document somewhere the names of the people in
charge of stuff; it seems many pieces of the websites items don't have real
maintainers but just good hackers that just don't have enough time to do
everything. On the other hand, if no-one is in charge, we should put
*Maintainer/moderator needed* at the place where the name should appear, so that
someone steps up, who could be just the person in charge of poking in turn the
right people. So, it would be a great idea IMO to have a `Websites/Contact
points` wiki page.
Awaiting comments. I'll try to produce a reasonable `diff` soon.
-d
[1]:http://www.redhat.com/archives/fedora-websites-list/2006-June/thread.h...
--
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
1 a.m.
On 11/19/06, Dimitris Glezos <dimitris(a)glezos.com> wrote:
(CCing art-list)
Hi all.
I've made some CSS/foo for the wiki. Here are some screenshots:
http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning
I like the new design. You have my vote.
Regards,
--
Thomas Chung
http://fedoraproject.org/wiki/ThomasChung
1:52 a.m.
Dimitris:
On 11/19/06, Dimitris Glezos <dimitris(a)glezos.com> wrote:
The design of the wiki is a *major* marketing issue and the artwork team should
have the opportunity to tune and increase the wiki's usability. It would be
great if *tomorrow* we could make the website more usable and accessible,
wouldn't it? :)
I second the vote.
Since I'm brand new to fedora-websites, let me just say that I have
been active in
the fedora-docs team for the the past 3 months. I couldn't agree more
that the wiki
(with all of its flaws) is one of the primary "public faces" for the
Fedora Project.
There's a lot of discussion and effort in the Fedora Docs team working
towards the
same goals of making "the website more usable and accessible".
John Babich
http://fedoraproject.org/wiki/JohnBabich
7:28 a.m.
O/H Thomas Chung έγραψε:
On 11/19/06, Dimitris Glezos <dimitris(a)glezos.com> wrote:
> (CCing art-list)
>
> Hi all.
>
> I've made some CSS/foo for the wiki. Here are some screenshots:
>
> http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning
I like the new design. You have my vote.
Thanks Thomas.
Since no-one had any objections, maybe we should go forward with this.
Here is an action plan:
1. Make some further improvements and upload an HTML version (22/11)
2. Get some test/feedback from `fedora-websites-list` members (24/11)
3. Notify mailing lists about the action (when it will happen and where to send
comments/bugs)
4. Just do it (tm) :)
-d
--
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
8:36 a.m.
Hi Dimitris,
Dimitris Glezos wrote:
O/H Thomas Chung έγραψε:
> On 11/19/06, Dimitris Glezos <dimitris(a)glezos.com> wrote:
>> I've made some CSS/foo for the wiki. Here are some screenshots:
>>
>> http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning
> I like the new design. You have my vote.
Thanks Thomas.
Since no-one had any objections, maybe we should go forward with this.
For what it's worth, I think these proposed modifications look fabulous!
It's very clean and makes the level of hierarchy each piece of
information is in on the page much more clearer.
One additional thing I would suggest - if you can do it and think it is
a good idea - is to add a spot in the right nav on the wiki for little
banners to advertise Fedora subprojects and events, etc. This is
something we had talked about on the marketing list I think a long time
ago - http://people.redhat.com/duffy/misc/fedoramentor-banner.png
(although might be better on the top).
Here is an action plan:
1. Make some further improvements and upload an HTML version (22/11)
2. Get some test/feedback from `fedora-websites-list` members (24/11)
If you want to do a formal usability test let me know and I can help out
with that. I'll be on vacation these 22/11 - 26/11 so I'll have time! :)
Thanks for taking charge on this Dimitris! We've needed this for a long
time. :)
~m
9:15 a.m.
On Tuesday 21 November 2006 08:36, Máirín Duffy wrote:
For what it's worth, I think these proposed modifications look fabulous!
It's very clean and makes the level of hierarchy each piece of
information is in on the page much more clearer.
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.
One additional thing I would suggest - if you can do it and think it is
a good idea - is to add a spot in the right nav on the wiki for little
banners to advertise Fedora subprojects and events, etc. This is
something we had talked about on the marketing list I think a long time
ago - http://people.redhat.com/duffy/misc/fedoramentor-banner.png
(although might be better on the top).
Design elements like that require alterations to the Python part of the theme.
That's something that we're reluctant to play with too much. If someone
really wanted to take the time to produce such elements that could then be
further edited without playing with the Python code, more power to them.
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.
> Here is an action plan:
>
> 1. Make some further improvements and upload an HTML version (22/11)
>
> 2. Get some test/feedback from `fedora-websites-list` members (24/11)
You'll need to push your dates back a little, as we're upon an American
holiday (Thanksgiving) tomorrow, and I'm sure many contributors will be
preoccupied for the next several days.
--
Patrick "The N-Man" Barnes
nman64(a)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/
--
9:46 a.m.
On Wednesday 22 November 2006 10:15, Patrick W. Barnes wrote:
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.
Well I usually have to bump up the text size when I read wiki pages. Maybe my
eyes are too sucky and my resolution too great, but I always find the default
wiki font sizes to be too small and I bump them.
--
Jesse Keating
Release Engineer: Fedora
11:55 a.m.
On Wed, 2006-11-22 at 10:46 -0500, Jesse Keating wrote:
On Wednesday 22 November 2006 10:15, Patrick W. Barnes wrote:
> 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.
Well I usually have to bump up the text size when I read wiki pages. Maybe my
eyes are too sucky and my resolution too great, but I always find the default
wiki font sizes to be too small and I bump them.
I absolutely agree. With the resolution on affordable monitors and LCD
panels increasing, these tiny fonts are definitely hard to read. I use
a user CSS page to fix that problem, but requiring new users to do that
is silly. A better solution would be a cookie and at least a simple
"small, medium, large" selector on the screen.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project Board: http://fedoraproject.org/wiki/Board
Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject
4:11 p.m.
On Friday 24 November 2006 11:55, Paul W. Frields wrote:
On Wed, 2006-11-22 at 10:46 -0500, Jesse Keating wrote:
> On Wednesday 22 November 2006 10:15, Patrick W. Barnes wrote:
> > 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.
>
> Well I usually have to bump up the text size when I read wiki pages.
> Maybe my eyes are too sucky and my resolution too great, but I always
> find the default wiki font sizes to be too small and I bump them.
I absolutely agree. With the resolution on affordable monitors and LCD
panels increasing, these tiny fonts are definitely hard to read. I use
a user CSS page to fix that problem, but requiring new users to do that
is silly. A better solution would be a cookie and at least a simple
"small, medium, large" selector on the screen.
While it would be great to have an option for changing the font size on the
fly, that would be complex to add to the wiki. Most browsers already have
features to easily adjust font sizes, so we just need to set a reasonable
default. Keep in mind that the majority of viewers are still going to be
using 1024x768 or even 800x600.
The problem I see in the current stylesheets is the use of fixed font sizing
(".75em"), which results in extremely small fonts in some browsers with
certain configurations. Using relative sizing ("small") instead of fixed
sizing should allow browser configurations to determine what a comfortable
font size should be. A properly-configured browser should then alleviate the
need to make per-site or per-visit adjustments.
--
Patrick "The N-Man" Barnes
nman64(a)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/
--
7:58 p.m.
O/H Patrick W. Barnes έγραψε:
On Tuesday 21 November 2006 08:36, Máirín Duffy wrote:
> For what it's worth, I think these proposed modifications look fabulous!
> It's very clean and makes the level of hierarchy each piece of
> information is in on the page much more clearer.
Since most of the comments were positive, I went on and produced a CSS that
overrides the default theme values.
http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning/CSS?action=raw
To test it, go to `UserPreferences` and put the above in the "User CSS URL"
box.
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).
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.
> One additional thing I would suggest - if you can do it and think
it is
> a good idea - is to add a spot in the right nav on the wiki for little
> banners to advertise Fedora subprojects and events, etc. This is
> something we had talked about on the marketing list I think a long time
> ago - http://people.redhat.com/duffy/misc/fedoramentor-banner.png
> (although might be better on the top).
Design elements like that require alterations to the Python part of the theme.
That's something that we're reluctant to play with too much. If someone
really wanted to take the time to produce such elements that could then be
further edited without playing with the Python code, more power to them.
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.
We might need some more changes, like putting a <div> around the table of
contents to manipulate it through CSS.
-d
--
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
8:02 p.m.
O/H Dimitris Glezos έγραψε:
O/H Patrick W. Barnes έγραψε:
> On Tuesday 21 November 2006 08:36, Máirín Duffy wrote:
>> For what it's worth, I think these proposed modifications look fabulous!
>> It's very clean and makes the level of hierarchy each piece of
>> information is in on the page much more clearer.
Since most of the comments were positive, I went on and produced a CSS that
overrides the default theme values.
http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning/CSS?action=raw
To test it, go to `UserPreferences` and put the above in the "User CSS URL"
box.
Don't know why, but the above URL doesn't always work. If you don't see any
difference, use the following URL:
http://dimitris.glezos.com/box/foss/fedora/custom.css
Sorry for the second email.
-d
--
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
12:28 p.m.
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(a)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/
--
9:10 a.m.
On Wed, 2006-11-29 at 12:28 -0600, Patrick W. Barnes wrote:
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.
Do we have some folks who want to hack Moin Moin code for Fedora? We
have the makings of a good relationship with them, and we can certainly
benefit if we get to make cool hacks and get them upstreamed.
Another reason I ask is that we need some help in this area for the
Documentation Project; I posted a help wanted message at:
https://www.redhat.com/mailman/private/fedora-infrastructure-list/2006-No...
- Karsten
--
Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
10:04 a.m.
O/H Patrick W. Barnes έγραψε:
> 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.
Patrick,
since most of the CSS changes were positively commented, wouldn't it be a good
idea to include the custom CSS in the upgrade before announcing it?
It would also be great if the team could publish on the list it's progress so
that the whole websites-list could participate or give constructive comments.
The more open the process, the better, right? :)
> 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.
Keeping things posted upstream is great and very important. But, we are a big
project and have many and special requirements; some of them are so special (eg.
have a banner on the right-hand menu for the Mentors program) that might require
coding that doesn't fit to the upstream.
Anyway, this is a very special discussion that doesn't have a black-or-white
answer, but only a rule-of-thumb: The more the upstream, the better. :)
BTW, the TOC-stylesheet thing appears to be implemented in 1.5/1.6, no?
http://moinmoin.wikiwikiweb.de/MoinMoinPatch/AlterTableOfContentsAppearan...
-d
--
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
12:35 p.m.
On Monday 04 December 2006 10:04, Dimitris Glezos wrote:
since most of the CSS changes were positively commented, wouldn't it be a
good idea to include the custom CSS in the upgrade before announcing it?
It would also be great if the team could publish on the list it's progress
so that the whole websites-list could participate or give constructive
comments. The more open the process, the better, right? :)
They aren't revising the site in any way. They're only working on the backend
software that powers it. Once they've finished the upgrade, we can start
working on any style patches. Their work is very straightford and doesn't
require any input beyond bug reports.
>> 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.
Keeping things posted upstream is great and very important. But, we are a
big project and have many and special requirements; some of them are so
special (eg. have a banner on the right-hand menu for the Mentors program)
that might require coding that doesn't fit to the upstream.
A banner on the side is something that would be implemented in the Python code
for the theme we're using, whereas changing the way ToC elements are produced
would require changes in the MoinMoin core. We're open to theme changes, but
we don't want to implement core changes that haven't been implemented
upstream.
Anyway, this is a very special discussion that doesn't have a
black-or-white answer, but only a rule-of-thumb: The more the upstream, the
better. :)
Indeed.
BTW, the TOC-stylesheet thing appears to be implemented in 1.5/1.6, no?
http://moinmoin.wikiwikiweb.de/MoinMoinPatch/AlterTableOfContentsAppearance
WithStyleSheet
That's my understanding.
--
Patrick "The N-Man" Barnes
nman64(a)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/
--
9:35 a.m.
On Tue, 2006-11-21 at 09:36 -0500, Máirín Duffy wrote:
Hi Dimitris,
Dimitris Glezos wrote:
> O/H Thomas Chung έγραψε:
>> On 11/19/06, Dimitris Glezos <dimitris(a)glezos.com> wrote:
>>> I've made some CSS/foo for the wiki. Here are some screenshots:
>>>
>>> http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning
>> I like the new design. You have my vote.
>
> Thanks Thomas.
>
> Since no-one had any objections, maybe we should go forward with this.
For what it's worth, I think these proposed modifications look fabulous!
It's very clean and makes the level of hierarchy each piece of
information is in on the page much more clearer.
+1. Nice, simple, understated, but very clear to the eye. Great job
Dimitris!
One additional thing I would suggest - if you can do it and think it
is
a good idea - is to add a spot in the right nav on the wiki for little
banners to advertise Fedora subprojects and events, etc. This is
something we had talked about on the marketing list I think a long time
ago - http://people.redhat.com/duffy/misc/fedoramentor-banner.png
(although might be better on the top).
+1 again. That would help give the Mentors program a much-needed kick
in the hindparts. I've observed lots of willingness but very little
connectivity to the community; with the number of daily hits on our
wiki, surely this would result in an increase of activity.
> Here is an action plan:
>
> 1. Make some further improvements and upload an HTML version (22/11)
>
> 2. Get some test/feedback from `fedora-websites-list` members (24/11)
If you want to do a formal usability test let me know and I can help out
with that. I'll be on vacation these 22/11 - 26/11 so I'll have time! :)
Thanks for taking charge on this Dimitris! We've needed this for a long
time. :)
Maybe Dimitris could also lead an overhaul on the front page! ;-)
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project Board: http://fedoraproject.org/wiki/Board
Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject
6350
days inactive
6364
days old
websites@lists.fedoraproject.org
15 comments
8 participants
participants (8)
-
Dimitris Glezos -
Jesse Keating -
John Babich -
Karsten Wade -
Máirín Duffy -
Patrick W. Barnes -
Paul W. Frields -
Thomas Chung