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 Newsgroups1. 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.htmlI 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
PGP.sig
Description: This is a digitally signed message part
