[native-lang] Re: [website-dev] getting all mailing lists into mailing lists list

I'll try replying to all three of you here. Thankyou to all of you  
for your help with this. :)

Kate said:

On 08/12/2006, at 3:48 AM, Kay Schenk wrote:
>
> Why don't you just mock something up and put it someplace for us to  
> have a look? I agree that some things are rather difficult to find.  
> So...let's see what you come up with. :)

I'll do that, if we all think that's still useful. Please see further  
down: Bernhard talks about building this into an improved Projects page.

What I'm looking at is improving the access of the first-time or  
newish user, who doesn't understand the structure of the OOo project,  
and just wants to get an overview and find a specific list or project.

In my experience over the past few months as a new and newish  
participant, currently it's very difficult to get an overview, and  
not trivial to find a specific project or list. You can go around in  
circles on the website. It's a real time-waster.
>
>> I envisage something like a Site Map, possibly with an easily- 
>> recognizable icon for each main project/category. Each main part  
>> has several child items, then the "More lists..." link.
>> It would give the user an overview of the OOo lists, which  
>> currently we don't have. It constructs a viable hierarchy of  
>> information.
>> I also propose each main project/category choose one list to be  
>> their root information target, and labelled as such on these pages  
>> (small icon, different colour), identifying it as the list for  
>> that group to which you should send new information.
>
> hmmm...not too sure what you mean by this actually

In an hierarchy of information, when spreading information, you are  
the information source, and where you want it to arrive is the  
information target. A root information target is the key place to  
send information so everyone in that group should get it.

For example, that can be the dev@ list for each project. It should be  
the list for each project to which everyone is subscribed. Not one of  
the lists that only some people read.

As another example, the main wiki page for a project could be its  
root information source. When you don't have the root information  
addresses, you can often miss out on background and contextual  
information, even major points, which everyone assumes you know.  
Having access to the root means you're starting at the same point as  
everyone else, or you should be. ;)
>
>> It's very difficult for someone outside your project to know how  
>> you handle your information flow. Designating a root information- 
>> target list shows people where to send that first email saying:
>> "We're looking at/starting X. These are our aims. These people are  
>> involved. Please see our main wiki page/webpage. [link] We invite  
>> you to contribute by..."
>> I would like to work on this. What do you think?
>
> Go for it!

Thanks for your encouragement. :)

Charles then said:

> FYI: this is the mailing list page as it stands today: do you think  
> it could be a good base to start with?
> http://www.openoffice.org/mail_list.html

It contains a lot of useful info, but, especially at first glance,  
it's very wordy and crowded.

The first screenfull is all words, no graphics, nothing to catch the  
eye or give the user an overview. I know these are words we want the  
user to read, but first-up, we need to catch their eye and show them  
we have what they're looking for.

A lot of first-time users will simply click away from that page,  
because the first screenful isn't the list of mailing lists they're  
looking for.

I'm no graphic designer, but I'd advise employing some icons for the  
main points:

[icon: magnifying glass] Search [extra link:Advanced]
[icon: map or layout] Mailing List Map
[icon: tickmark?] Using our Lists
[icon: Gmane?] Lists as Newsgroups

1. I don't know how effective the Search is, but I haven't found it  
very effective myself. I don't know why. Maybe I've just been  
unlucky. An Advanced Search link, to take the user straight to a  
categorized search, would also be useful.

2. The "Mailing List Map" is what I've been talking about. An  
overview. Each project has its own category, and its own icon. Its  
name is a link to its own project page. Its main lists are shown  
below its name, with tooltips explaining their purposes, and a "More  
lists..." link after the set number has been shown.

I do think this can link in with the Projects page. I apologize for  
not catching up with that sooner: I just didn't have time to read all  
the messages on that thread. I will try to catch up.

3. "Using our Lists" is the info now shown under the search box, and  
at the end of the page.

4. "Lists as Newsgroups" is the Newsgroups section.

The page would now focus on those four items, well spaced-out with  
graphics. I think it would catch a lot more attention, and help the  
users.

The table of lists further down the page has quite a lot of useful  
info, but it's really ugly. It's too big, and the lack of balance  
between the amount of text in the first column and in the other  
columns is way too pronounced. This would all now be on the Mailing  
List Map page. A Join or Browse link for each category would take the  
user to the page where s/he can do those actions.

This does make it three clicks for the user looking for a general  
mailing list, but it makes it much easier, I think, for the user to  
find other mailing lists.

This is just an idea: as I said, I'm no graphic designer. But I don't  
think the page works, currently. We need to engage the user.

Then Bernhard said:
>
> My problem is not only the number of lists, but that many topics  
> start on a not really suitable list. If you are not subscribed to  
> this specific list, you'll miss that topic.
>
> Sometimes the topic is changing slightly, so you don't even know  
> exactly when to switch to another list.
>
> But this is not what we'd like to discuss here...

It's an important point, though. I don't know how we can fix this  
problem, but we can emphasize the domain of lists on the project page  
and/or Mailing List Map.
>
> I like your idea, but in fact this sounds more like an updated  
> *projects* page than a mere mailing list list.
>
> The informations you want to add to the lists are informations  
> about what is being done in the projects (if I understand you  
> correctly).
>
> Main points:
> - What is be done in which project
> - link to the projects homepage
> - link to it's dev mailing list (archive?), as this list should be  
> the main project list (if there is another one more important for  
> the project, it might be linked instead or additionally)
> - perhaps a link to the users mailing list of a native-lang project.
>

Yes, it would do those jobs, too. I'm thinking that users may be  
looking for info by mailing list, or by project. So both pages would  
be used. They both reinforce the hierarchic structure of OOo, and  
give an overview. Or we could still work on the Mailing Lists page,  
and one of the main links could be Mailing Lists by Project, to the  
improved Project page.

>> I envisage something like a Site Map, possibly with an easily- 
>> recognizable icon for each main project/category.
>>
>
> An icon for each project would be great!
> It could be presented on it's homepage (larger) and on each sub  
> page in a smaller scale.

I do think we need more visual content.
>
> This might improve the look of the pages for a "standard user" and  
> - using a common style for the icons - keep the unified impression  
> of the pages at the same time.

Yes! That would also remove some of the "fragged" feeling around OOo:  
each site does things differently. Having some uniform graphics,  
which catch the eye and thus tend to identify a site, would create a  
default identity to which projects can add. Currently, there's no  
visual default identity, except the OOo icon in the top LH corner. I  
think we need more graphics that can be used widely. We could even  
work with some of the icons from OOo, but some of them aren't very  
intuitive, either. :S
>
>
>>  Each main part
>> has several child items, then the "More lists..." link.
>>
>
> I assume that people searching for a specific mailing list would  
> know in which project to look for it.

Not necessarily. That's part of the problem.

Let's say you're a user who is interested in templates. You want to  
ask questions about templates, or submit some. How do you know which  
project handles templates?

Or you have questions about the issue-tracker. Or you want to discuss  
how OOo works on your specific architecture. The main users list does  
a great job of redirecting users, but apart from that, they're left  
blundering around on the website. We need to show them an overview.

> For all the others the informations on the  projects/lists page  
> need to be sufficient to find the right project/category.

But how do they know to look on the projects page in the first place? :)

You start at the homepage of a site.
http://openoffice.org/
tells you how to get the product, which is good. It does include  
links called Contributing and Support, but for someone who has  
started to contribute, the rest of the project is a confusing mass of  
sub-projects in a structure s/he doesn't understand. Contributors  
need a root information source page. If Projects is that page, we  
need to make sure all new contributors know about this page, somehow.  
I didn't even know there _was_ a Projects page, until you mentioned  
it on this list. And  I've been here for several months now.
>
> The reason for the main mailing list and the "more lists..." (.../ 
> servlets/ProjectMailingListList.html) is clear. But what kind of  
> child items do you think of?
>
> For example:
>
> The Germanophone project contains besides [email protected] and  
> [email protected] a specific marketing list ([email protected]), a list  
> for coordination of the "PrOOo-Box", our CD-Rom subproject  
> ([email protected]), a list for the OOo camp ([email protected]), where we  
> coordinate weekend meetings with young people, and several others.
>
> All of them are Germanophone, so I think most of the people  
> searching for such a list will start at http://de.openoffice.org.
>

Only if they understand how the OpenOffice project and domain system  
works. We can't assume they do.

On a Mailing List Map page, I was envisioning blocks like this:

Project Name [is also link to Project homepage, has unique icon]
Mailing List 1 [is also root information target, has identifying icon  
or differing colour]
Mailing List 2
Mailing List ...
Mailing List X [set number of child items]
Join, browse or see more lists... [link to http://X.openoffice.org/ 
servlets/ProjectMailingListList for this project]

Each item has a tooltip describing its purpose. This saves space.

We still have a lot of items for one page, but it's a start. :)

>> It would give the user an overview of the OOo lists, which  
>> currently we don't have. It constructs a viable hierarchy of  
>> information.
>>
>
> That's right.
>
> But linking to the lists is not enough - much more informations are  
> stored at the web pages of the corresponding projects. So I'd think  
> it to be better to refer people asking for advise to the project's  
> pages instead to the mailing lists only.

This was specifically for people looking for mailing lists. Each  
project heading would include a link to that project page.
>
> If someone wants to inform people inside a specific project about  
> what's going on elsewhere, I think the dev-list should be sufficient.
>

If they nominate that list as their root list, people will be able to  
identify it as the place to send information. Nobody can then claim  
they don't know where to send info. ;)

>> I also propose each main project/category choose one list to be  
>> their root information target, and labelled as such on these pages  
>> (small icon, different colour), identifying it as the list for  
>> that group to which you should send new information.
>>
>
> That should be the dev-list on all projects, I think.
>

It might be. It should be clear that "information" is a simple  
statement of aims, with a  link to the main info. page. It doesn't  
mean overloading the list; it means just sending a notification that  
you're doing something, with a brief description, some participants'  
names and a link so members can follow it up if they like.

>> It's very difficult for someone outside your project to know how  
>> you handle your information flow. Designating a root information- 
>> target list shows people where to send that first email saying:
>> "We're looking at/starting X. These are our aims. These people are  
>> involved. Please see our main wiki page/webpage. [link] We invite  
>> you to contribute by..."
>>
>
> This *must* be a major part of the project's home page IMHO. Before  
> joining a mailing list people should know about what the project is  
> doing.

I think they would. They can see an overview of the mailing lists,  
and the names of the most commonly-used ones, but they can't actually  
_join_ a list without going to the project page for those lists. ;)
>
> Perhaps I got you totally wrong, but in my eyes all you describe  
> could be part of the to-be-updated projects page:
>
> http://projects.openoffice.org/index.html
>
>> I would like to work on this. What do you think?
>>
>
> Please do so, if you think your goal is different from that what  
> the update of the projects page aims for.
>
> But if you think this efforts could be combined, this might lead to  
> a totally different projects page - with relevant informations  
> about all the projects for developers, other contributors and mere  
> users...

I'd like to help with that. I still think the Mailing Lists page  
could be updated, as well. I'm mostly speaking of my own experiences  
as a newish member of the project, and new user. I've spent a lot of  
time in different projects, so I think, "If I'm confused here, what  
is it like for people new to computing or to community efforts?"

I'm no expert on webpage design, but I'm willing to help if I can. I  
do think we need to engage the user more, especially graphically.

from Clytie (vi-VN, Vietnamese free-software translation team / nhóm  
Việt hóa phần mềm tự do)
http://groups-beta.google.com/group/vi-VN