This is my proposal for the WineHQ menu structure, based on the discussions I had with Francois.
The Home Page should just be our news page. Many projects opt for this, and I think it's good: News are 'zero' click items. It should consist of the WNN box to the right (as our current home page), and a bigger central box for announcements. Each box should have a link at the bottom to their respective archive pages.
Below, the numbers are for reference only, they should not appear on the site.
Top Level ---------
1. About 2. Status 3. Screenshots 4. Download 5. Support 6. Documentation 7. Development 8. Contributing 9. Forums
Expanded --------
1. About 1.1 Intro 1.2 Why Wine 1.3 Myths 1.4 Technology 1.5 History 1.6 Related projects 1.7 Who's Who 1.8 Community 1.9 Companies 1.10 Contacts 1.11 Legal (1.1-1.3 may be collapsed in one page, that is served when you click on About; there are too many subitems like this) 2. Status (our current status page, with links to TODOs, etc) 3. Screenshots (add real sexy shots, as discussed in other mail) 4. Download (link to tarballs, and binary packages) 5. Support 5.1 FAQ 5.2 Howto 5.3 Bugzilla 5.4 Troubleshooting 5.5 Application database 5.6 Commercial support 6. Documentation 6.1 User Guide 6.2 Developer Guide 6.3 Packager Guide 6.4 API Docs 7. Development 7.1 Source (page with explanation of the CVS trees, LXR, cvsweb, etc.) 7.2 Developer Hints 7.3 Submitting Patches 7.4 Outstanding Work (page with the 0.9/1.0 TODOs, Tasklist/bug 395, FIXMEs/bug 455, Tasklets/bug 406, most wanted bugs) 7.2 Tools 7.3 References (Win32 documentation, X doc, etc.) 8. Contributing 8.1 Application maintainer 8.2 Bug triage 8.3 Website maintenance 8.4 Development (short page with links to the development section) 8.5 Support Wine-based products 9. Forums 9.1 Mailing Lists 9.2 Newsgroup 9.3 IRC Channel
-----
So we don't forget, some related bugs in Bugzilla:
Other relevant Web Site tasks -----------------------------
* 597 - How to get the web site files * 598 - Update the Who's Who * 600 - Add a Site Map * 601 - Add drop-down menus * 605 - Add 'tables of contents' * 607 - Add screenshots * 608 - Reorganize the Web site
- 607 - Add screenshots
Where would screenshots be contributed to? Mailed to wine-devel? Appended to the bug entry in bugzilla?
Chris
On November 2, 2002 07:14 pm, Chris Morgan wrote:
Where would screenshots be contributed to? Mailed to wine-devel? Appended to the bug entry in bugzilla?
I don't know. Append them in bugzilla I guess. We're going through a site redesing anyway, so we should find a way for people to contribute.
On Sat, 2 Nov 2002, Chris Morgan wrote:
- 607 - Add screenshots
Where would screenshots be contributed to? Mailed to wine-devel? Appended to the bug entry in bugzilla?
Actually, the larger issue is:
where should Web site discussions take place and where should patches go?
The 'How to contribute' section says to do it through web-admin@winehq.com. But I think it would be better to:
* discuss all web site related issues on wine-devel * send web site patches to wine-patches
We just need someone to monitor wine-patches and apply the relevant patches and I'm sure Alexandre will have no problem ignoring the web related patches. I also don't think the traffic on either wine-dev or wine-patches justifies creating one or even two more mailing lists. It's best to do it more in the open where everyone can watch and get involved.
However wine-cvs should only get Wine commits. If something similar is needed for the web site (might be nice) then it should go to another mailing list.
On Saturday 02 November 2002 05:03 pm, Dimitrie O. Paun wrote:
This is my proposal for the WineHQ menu structure, based on the discussions I had with Francois.
The Home Page should just be our news page. Many projects opt for this, and I think it's good: News are 'zero' click items. It should consist of the WNN box to the right (as our current home page), and a bigger central box for announcements. Each box should have a link at the bottom to their respective archive pages.
What is the difference between "support" and "documentation"? Isn't a FAQ or a troubleshooting guide documentation? These two should be merged to make the website simpler to use. If I want to find the FAQ, I don't want to guess what section it's in. Also, what's the difference between "development" and "contributing"? It's not immediately clear; maybe the section should be part of the development section..
--- Igor Izyumin igor@mlug.missouri.edu wrote:
On Saturday 02 November 2002 05:03 pm, Dimitrie O. Paun wrote:
This is my proposal for the WineHQ menu structure, based on the discussions I had with Francois.
The Home Page should just be our news page. Many projects opt for this, and I think it's good: News are 'zero' click items. It should consist of the WNN box to the right (as our current home page), and a bigger central box for announcements. Each box should have a link at the bottom to their respective archive pages.
What is the difference between "support" and "documentation"?
Support is when you ask a person a question and you get an answer to that question. Documentation is pre-written and may or may not answer your question.
Isn't a FAQ or a troubleshooting guide documentation?
Yes they both are, but a FAQ is where you get a list of frequently asked questions and their answers, whether it is a problem or just a general question, such as "what is wine?", which shouldnt go into a troubleshooting guide. Troubleshooting guides are there to help someone find out if a problem they are having is known about or not and if so, how to fix it.
These two should be merged to make the website simpler to use.
See above for why I disagree.
If I want to find the FAQ, I don't want to guess what section it's in.
You wont have to, it will be in the FAQ section. And to anyone else reading this, if this isnt the case, then it should be 2 links on the main page, 1 to the FAQ and 1 to the _Troubleshooting Guide_. He is right, if there isnt a blatent link to the FAQ or a troubleshooting guide on the _main_ page we will probably lose 5-10% of people that would try wine just because they dont want to have to search through the site to find it. I had a hard time making heads and tails of the official wine documentation when i was a wine newbie...
Also, what's the difference between "development" and "contributing"? It's not immediately clear; maybe the section should be part of the development section..
Development is where you get hints on actually implementing a missing feature, where its up to you as to whether you contribute it to the main project or not. Contributing is when you actually send it to the developers for inclusion.
__________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
5.5 Application database
I think the application database is buried too deep here; I think it should be, if not top level, a main entry under 'Status'.
Also, I want to make sure that I am in a minority here in feeling that the proposed structure is going in the wrong direction. I think a better design is fewer, simpler, choices at each level.
I was the primary driving force behind the current top level menu, so if everyone else thinks I'm full of beans, I'll shut up and go away (but not without my long winded say, of course <grin>).
However, I think that when someone comes to a home page, they really have only the following major questions: What is this? How do I get it? Hey! It's busted! Help! How can I help? What's New?
For example, in your proposed structure, it is completely unclear to me what the difference between Support and Forums is. The IRC channel is one of our best support tools... but it's under Forums? Similarly, what's the difference between Development and Contributing?
So, I propose the following instead:
First, this assumes that we use Jeremy Newman's idea of a rotating screen shot on main page, and continued prominence of the news.
1. What is Wine? 1.1 Intro 1.2 Technology (very high level overview) 1.3 Why Wine 1.4. Will it run my app? Screenshots/Appdb 1.5 History 1.6 Current Status 1.6.1 Status 1.6.2 Projected milestones/timelines 1.7 Community 1.7.1 Who's Who 1.7.2 Related projects 1.7.3 Companies 1.8 Contacts 1.9 Legal
I actually think having a sequence of shorter pages is much more powerful than having an intimidatingly long page.
2. How do I get Wine? (link to tarballs, and binary packages, cross link to the development pages re CVS)
3. Help!
3.1 FAQ 3.2 Documentation 3.2.1 Users Guide 3.2.2 Developers Guide 3.2.3 Troubleshooting (I left this in, but I don't know what it means) 3.2.4 Other documentation 3.2.4.1 Howto 3.2.4.2 Packagers doco 3.2.4.3 API Docs 3.3 Forums 3.3.1 Mailing Lists 3.3.2 Newsgroup 3.3.3 IRC Channel 3.4 Bugzilla 3.5 Commercial support
4. How do I get involved? 4.1 Application maintainer 4.2 Bug triage 4.3 Website maintenance 4.4 Development (short page with links to the development section)
4.4.1 Source (page with explanation of the CVS trees, LXR, cvsweb, etc.) 4.4.2 Developer Hints 4.4.3 Submitting Patches 4.4.4 Outstanding Work (page with the 0.9/1.0 TODOs, Tasklist/bug 395, FIXMEs/bug 455, Tasklets/bug 406, most wanted bugs) 4.4.5 Tools 4.4.6 Documentation (cross link back to doco)
4.5 Support Wine-based products
</long winded pitch>
I'm willing to be voted down here; I just wanted to make sure we weren't just being bullied into accepting a complicated structure.
Cheers,
Jer
On 2 Nov 2002, Jeremy White wrote: [...]
For example, in your proposed structure, it is completely unclear to me what the difference between Support and Forums is. The IRC channel is one of our best support tools... but it's under Forums?
I'm not sure non-technical users would have the reflex to turn to IRC to get help. But maybe that's because I'm too old and prefer mailing lists. Anyway, forums are places where people talk to each other. Doesn't that nicely cover newsgroups, mailing lists and irc?
Similarly, what's the difference between Development and Contributing?
I think they are for a different audience. Also I am not sure it makes sense to put the content of the two on the same page. See for yourself:
http://www.winehq.com/about/index.php?contrib http://www.winehq.com/development/
[...]
I actually think having a sequence of shorter pages is much more powerful than having an intimidatingly long page.
Frankly I prefer longer pages. But yes, there's a balance to strike. It's partly an issue of length, and partly an issue of whether all the content on the page is related, and presentation (e.g. I would not put Bugzilla's 'home page' in between two paragraphs).
[...]
- Help!
3.1 FAQ 3.2 Documentation 3.2.1 Users Guide 3.2.2 Developers Guide 3.2.3 Troubleshooting (I left this in, but I don't know what it means) 3.2.4 Other documentation 3.2.4.1 Howto 3.2.4.2 Packagers doco 3.2.4.3 API Docs 3.3 Forums 3.3.1 Mailing Lists 3.3.2 Newsgroup 3.3.3 IRC Channel 3.4 Bugzilla 3.5 Commercial support
How is this simpler that Dimitrie's proposal (or mine)?
Most of the items are three levels deep! Not just in the excerpt above, throughout your menus. Some are even four levels deep. How do you display such a deep menu hierarchy on a web page? Sure you can but it will neither look good nor look simple.
In fact, the way it has been solved on the current Web site is by showing nothing except the top-level items. Here's an exercise now, go to http://www.winehq.com. Now, tell me:
* what is Wine? * where is the IRC channel? * where is the application database? * where do I find screenshots? * is there a Wine newsgroup? * how do I contribute?
Too much nesting just hides information and forces the user to dig down to find what he is looking for. And if he can't figure out where to dig he has to try all of them in turn. I want for proof that this problem exists the sub-titles which have obviously been put there in an attempt to solve it. But they are incomplete (Help does not mention commercial support, Wine Development says 'etc.', that's useful!), and won't let you go directly to the relevant item. You first have to click on 'Wine Development' and then hunt again for another link to where you want to go.
I think it's well worth it to have more top-level items if we can bring the hierarchy depth down to just two levels.
Well, writing this made me realize that there are issues in my proposal (and Dimitrie's), so I will go there and try to explain what's wrong and fix it up.
On November 3, 2002 02:35 am, Francois Gouget wrote:
Too much nesting just hides information and forces the user to dig down to find what he is looking for.
I am sorry to do a AOL -- me too post, but I do agree 100% with Francois. For WineHQ, I _strongly_ feel it's a big mistake to have more than 2 levels of menus. Just top level, and a sublevel is more than enough.
Here are the principles I used for my proposal: 1. Just two levels 2. The more some info is accessed, the fewer mouse clicks should be required to get to it. 3. Menus organized by usage patterns, rather then strict technical category.
Please keep in mind that moving one item one level down in the menu hierarchy decreases its visibility by an order of magnitude, while keeping it on the higher level complicates that level only slightly.
The current menu is simple, but at the expense of making the info almost invisible! I'll give you one example: *I* (a long time Wine contributor), was aware of the status page (which I love) from the link that used to be provided in the WWN. The only way I new how to get to it was to look careful through some WWN for the little link to Status! At a certain point I could not find it anymore, I looked for it for minutes, just to give up thinking that it got deleted!!! I can continue to give examples on many pages, but if I can't get to the info, something's not right.
And a comment on usage patterns. You asked why the split between Development/Contributing, and Support/Documentation. This follows from Principle 3. They have _very_ different usage patterns, and audiences.
When a user has a problem, he goes with one click to the support area, where all the relevant info (and only that!) is available. No need to go jumping through the site, it's just another click away.
Similarly, for the Development/Contributing. Time and again OSS project push only the "Development" part in front, scarring away non-programmers from contributing, just to realize later on that they do need a lot of non-programming help as well. Case in point, instead of spending my time on the controls, I do other things that could be handled by non-programmers :). It's a natural split, the Development area is very important for Wine, and people going there are not interested in items that are listed in "Contributing"; also, we should show people there are many other ways to contribute, appart from coding. BTW, the Contributing section is is Francois idea, but I strongly support it.
Thing is, I am quite happy with the structure I put forward. Please review my desing principles, and lets see if we have any disagreement there. You must realize this is UI design, and everybody will have a different opinion. :) (So I must have mine)
On Sunday 03 November 2002 03:09 am, Dimitrie O. Paun wrote:
On November 3, 2002 02:35 am, Francois Gouget wrote:
Too much nesting just hides information and forces the user to dig down to find what he is looking for.
I am sorry to do a AOL -- me too post, but I do agree 100% with Francois. For WineHQ, I _strongly_ feel it's a big mistake to have more than 2 levels of menus. Just top level, and a sublevel is more than enough.
Here are the principles I used for my proposal:
- Just two levels
- The more some info is accessed, the fewer mouse clicks should be required to get to it.
- Menus organized by usage patterns, rather then strict technical category.
I agree with the first two, but the third is wrong. Information should not be split up into illogical categories based on what you think is a logical usage pattern. The fewer splits you can make, the better it is. If I'm looking for a FAQ, I would first click on Documentation, but if it's buried in "Support" I would not even bother clicking there. The best structure would have clear, logical categories and you would not have to guess where a certain document would be buried. Keep in mind that it is better to group all information into as few logical categories as possible. There should be no guessing involved.
[snip]
And a comment on usage patterns. You asked why the split between Development/Contributing, and Support/Documentation. This follows from Principle 3. They have _very_ different usage patterns, and audiences.
How about renaming support to "Get Help", Troubleshooting", or something like that. "Support" != self-help, and as a user, I would click on "Documentation" first. Support implies commercial support, and I would think (from experience with many other websites) that it would simply be a plug for Codeweavers, not an area with documentation.
Similarly, for the Development/Contributing. Time and again OSS project push only the "Development" part in front, scarring away non-programmers from contributing, just to realize later on that they do need a lot of non-programming help as well. Case in point, instead of spending my time on the controls, I do other things that could be handled by non-programmers :). It's a natural split, the Development area is very important for Wine, and people going there are not interested in items that are listed in "Contributing"; also, we should show people there are many other ways to contribute, appart from coding. BTW, the Contributing section is is Francois idea, but I strongly support it.
OK, this section needs to be renamed, too. 'contribute' is a transitive verb, and in a context of a free software project implies contributing code. A web guru would never click on a "contribute" link because they think it's instructions for sending in Wine patches. "Help out" or "Volunteer" or something like that would be much more accurate.
Thing is, I am quite happy with the structure I put forward. Please review my desing principles, and lets see if we have any disagreement there. You must realize this is UI design, and everybody will have a different opinion. :) (So I must have mine)
On Sun, Nov 03, 2002 at 07:52:09AM -0600, Igor Izyumin wrote:
On Sunday 03 November 2002 03:09 am, Dimitrie O. Paun wrote:
On November 3, 2002 02:35 am, Francois Gouget wrote:
Too much nesting just hides information and forces the user to dig down to find what he is looking for.
I am sorry to do a AOL -- me too post, but I do agree 100% with Francois. For WineHQ, I _strongly_ feel it's a big mistake to have more than 2 levels of menus. Just top level, and a sublevel is more than enough.
Here are the principles I used for my proposal:
- Just two levels
- The more some info is accessed, the fewer mouse clicks should be required to get to it.
- Menus organized by usage patterns, rather then strict technical category.
I agree with the first two, but the third is wrong. Information should not be split up into illogical categories based on what you think is a logical usage pattern. The fewer splits you can make, the better it is. If I'm looking for a FAQ, I would first click on Documentation, but if it's buried in "Support" I would not even bother clicking there. The best structure would have clear, logical categories and you would not have to guess where a certain document would be buried. Keep in mind that it is better to group all information into as few logical categories as possible. There should be no guessing involved.
Agreeing 100%.
Similarly, for the Development/Contributing. Time and again OSS project push only the "Development" part in front, scarring away non-programmers from contributing, just to realize later on that they do need a lot of non-programming help as well. Case in point, instead of spending my time on the controls, I do other things that could be handled by non-programmers :). It's a natural split, the Development area is very important for Wine, and people going there are not interested in items that are listed in "Contributing"; also, we should show people there are many other ways to contribute, appart from coding. BTW, the Contributing section is is Francois idea, but I strongly support it.
OK, this section needs to be renamed, too. 'contribute' is a transitive verb, and in a context of a free software project implies contributing code. A web guru would never click on a "contribute" link because they think it's instructions for sending in Wine patches. "Help out" or "Volunteer" or something like that would be much more accurate.
Great idea ! Contribute is in fact not "aggressive" enough, as it hides what the intentions behind that are.
On Sun, 3 Nov 2002, Igor Izyumin wrote: [...]
How about renaming support to "Get Help", Troubleshooting", or something like that. "Support" != self-help, and as a user, I would click on "Documentation" first. Support implies commercial support
True. It often has such a connotation and it might deter people. Though in my proposal the sub menus are clearly visible so they should still understand. 'Troubleshooting' would be nice but it already refers to the FAQ-O-Matic troubleshouting section...
OK, this section needs to be renamed, too. 'contribute' is a transitive verb, and in a context of a free software project implies contributing code. A web guru would never click on a "contribute" link because they think it's instructions for sending in Wine patches. "Help out" or "Volunteer" or something like that would be much more accurate.
What about 'Help Wanted'? I think it pretty much expresses what we want and is a bit stronger than just 'Contribute' which should please Andreas<g>.
On November 3, 2002 12:51 am, Jeremy White wrote:
However, I think that when someone comes to a home page, they really have only the following major questions: What is this? How do I get it? Hey! It's busted! Help! How can I help? What's New?
Partly, yes. But I think some very important questions are missing: How does it look like? What's the current status of this thing?
But beyond that, I find it a big mistake to name the menu "How do I get it?", and not "Download". When they want to get the source, people are not searching for the question. In fact, most of the time they don't search for the word, but a picture of the word.
Jer, there is a reason application menus are standard: File Edit View ... Help People have tried to get creative with menus, and it didn't lead to any good.
This question thingy is _completely_ non standard, and at least for me, a bit annoying. And being so non-standard, I think the burdon of proof it's on you to justify such a drastic departure from standard website design practice.
This question thingy is _completely_ non standard, and at least for me, a bit annoying. And being so non-standard, I think the burdon of proof it's on you to justify such a drastic departure from standard website design practice.
I have no objection to changing the titles away from the question thingy; I care mostly for the content.
I think my points revolve around the number of items on each page; I vote for fewer (7 is the number I recall being bandied about as the 'most' you shoud have).
If having the shallowest hierarchy is our overarching goal, why don't we just have all the entries on the main page?
Jer
On Sat, 2 Nov 2002, Dimitrie O. Paun wrote:
This is my proposal for the WineHQ menu structure, based on the discussions I had with Francois.
The Home Page should just be our news page. Many projects opt for this, and I think it's good: News are 'zero' click items.
I think the home page should be targeted to people who may not know what Wine is. Thus it should *answer* the question 'What is Wine'. The Gimp's web site (http://www.gimp.org/) is a good example in that respect. The first paragraph of the page answers the question 'What is the GIMP?'.
Thus I think there should be a link to the News page but no more. The news page is for returning visitors and if that's what they care about then they should bookmark that page rather than the home page.
Other things I have now realized:
* I said before I prefered a non-expanded menu (again, ala Gimp) to a fully expanded one. Now I changed my mind. If the menu is not fully expanded from the start then it's hard to figure out what the heck is in the unexpanded items. Proof: the current WineHQ site. Other proof, The Gimp's web site. Click on Documentation. Wow! Eleven items appear! Before expanding the menu, did you know that mailing list was in Documentation rather than in Resources? No? Well, you had no way of knowing anyway.
* having a fully expanded menu means we must have fewer items otherwise it risks being overwhelming. Things are not as bad as they seem because in my proposal I tried to include every item currently in the web site and I gave it a place in the hierarchy. But some of these items should not have a menu entry for themselves but just be a section on a page. Which brings me to the next item:
* there are ambiguities in the way we describe the menu hierarchy. Some items are not items at all but sections on a page. So now I will give numbers to menu items, '1.' or '2.3.', and letters to sections like 'a.' (plus an extra indentation). Pages that contain multiple sections should have a table of content which I imagine as being a box very much like the 'Wine Weekly News' box. Finally, if an item contains more than one thing I'll just put them in parenthesis. I realize that page sections are almost like third level menus. Jeremy is going to hang me saying this proposal is just as nested as his <g>. However I think mine has all the important items visible right there on the first page and not at the third level. Also I think this is just a consequence of trying to list everything that currently exists in the web site to make sure I'm not forgetting something (which may happen anyway) that we would then not know where to put.
* In the previous proposal we sometimes had two menu items that refered to the same thing. For instance:
> 1. About > 1.1 Intro
Both 'About' and 'Intro' point to the same place. At least that's how I understood it (and meant it in my proposal). Now I think this unnecessarily makes the menu longer but this is partly contingent to how the menu is presented. With some menu system 'About' may not be a hyperlink at all. Finally it may not always be natural to cook up a page that is meaning full for top-level items.
* One thing that causes me trouble is Bugzilla and the Application Database. I strongly feel that they must have a menu entry because they have to be accessible. But when you click on them you leave the WineHQ web site. For instance the WineHQ menu disapears and is replaced with either the Bugzilla or the Application Database menu. That bothers me and may be confusing. But I don't see anything we can do about that.
* That brings me to another point. I like the menus in Bugzilla and the Application Database: http://wine.codeweavers.com/bugs/ http://appdb.winehq.com/ I vote for using the same system for WineHQ. This would also bring a better unity of style. Each top-level menu is a 'box' that contains all the level two menu items.
* Who cares about an 'Applications Database'? What's that anyway? Would a potential Wine user want to have dealings with a database? Nah. Must be for geeks. What users want to know is what applications run in Wine and thus that's how the menu entry and the thing itself should be called: 'Supported Applications'. Even if the truth is that it lists applications that do not work too.
* I'm moving the Who's Who to the development section. Now it seems clear to me that people trying to have an idea about what Wine is don't care about Who's Who. On the other hand, developpers, i.e. people more involved with the project, would certainly be interested to know more about their fellow developpers (in fact it's almost a developper list).
* Contributing is important. I'm glad Dimitrie agrees with me. But now I'm not sure we should have a menu entry for each of its sections. So I moved it to 'About Wine'. This means it gets nearer where people new to Wine (i.e. who are not involved in Wine yet) are. Maybe that compensates a bit...
* In the same spirit there are things that must be there but that fewer people would look for. So I created a 'Misc' top-level section which would be the last section to regroup these and unclutter more important sections such as 'About Wine'. As a guiding principle I tried to imagine someone new to Wine who is not a developper, determine what he will want to see first, and put these first. Then come potential developpers but I know they will zoom in on the 'Development' and 'Forums' categories and go there.
So, here goes:
Home (no menu item for this one, just click on the Wine logo)
1. About Wine 1.1. Introduction a. Intro b. Why Wine c. Myths d. Technology e. History g. Companies 1.2. Screenshots 1.3. Supported Applications 1.4. Contributing a. Application maintainer b. Bug triage c. Website maintenance d. Development 1.5. News 1.6. Press
2. Download 2.1. Binaries (installing from binaries) 2.2. Source (installing from source) 2.3. CVS (installing from CVS)
3. Support 3.1. FAQ 3.2. Howto 3.3. Bug Tracking 3.4. Troubleshooting 3.5. Forums a. Mailing Lists b. Newsgroup c. IRC Channel
4. Documentation 4.1. User Guide 4.2. Developer Guide 4.3. Packager Guide 4.4. API Docs
5. Development 5.1. Developer Hints 5.2. Submitting Patches 5.3. TODO Lists - 0.9/1.0 TODOs - Tasklist/bug 395 - FIXMEs/bug 455, - Tasklets/bug 406 - most wanted bugs 5.4. Status 5.5. Resources a. LXR b. CVS Web c. Who's Who d. Tools e. Win32 Documentation, X doc, etc.
6. Miscellaneous 6.1. Community 6.2. Related projects 6.3. Contacts 6.4. Legal
'Just' 33 menu items (down from 44 for both Dimitrie's and Jeremy's proposals). WineHQ is a big site... Hopefully there's not too much hiding.
On Sunday 03 November 2002 04:28 am, Francois Gouget wrote:
On Sat, 2 Nov 2002, Dimitrie O. Paun wrote:
This is my proposal for the WineHQ menu structure, based on the discussions I had with Francois.
The Home Page should just be our news page. Many projects opt for this, and I think it's good: News are 'zero' click items.
I think the home page should be targeted to people who may not know what Wine is. Thus it should *answer* the question 'What is Wine'. The Gimp's web site (http://www.gimp.org/) is a good example in that respect. The first paragraph of the page answers the question 'What is the GIMP?'.
True, although the Gimp's website puts too much stuff above the fold. News should be on the very top, right after a three-sentence explanation of what it is. The rest (bugs, etc) belongs on a sidebar or floating box or something.
Thus I think there should be a link to the News page but no more. The news page is for returning visitors and if that's what they care about then they should bookmark that page rather than the home page.
Completely false. New visitors care about news as much as anyone else, and a healthy amount of news shows that the project is not dead. That is very important - a completely static front page usually means that the main developer has lost interest, and I would not download a project if it looks like nothing happened in the last month or two. The front page should have timely, relevant news, and should show what happened with Wine recently. That is very important: some pages might be outdated and could refer to some old version as being "most recent", and the user would be very confused unless they know that the new version was just released a day ago.
Don't be afraid of having a large front page. That's not bad. A lot of people think that it's bad when web pages scroll, and that's not bad at all. All of the information that is relevant in any way should be on the front page. It shouldn't be overwhelming, but it should answer all the questions that a user might have about Wine (what it is, how much it costs, how well it works, etc), show the things that happened recently, and
Besides, can you give me one example of a good website that doesn't have news on the front page?
On Sun, Nov 03, 2002 at 02:28:54AM -0800, Francois Gouget wrote:
On Sat, 2 Nov 2002, Dimitrie O. Paun wrote:
This is my proposal for the WineHQ menu structure, based on the discussions I had with Francois.
The Home Page should just be our news page. Many projects opt for this, and I think it's good: News are 'zero' click items.
I think the home page should be targeted to people who may not know what Wine is. Thus it should *answer* the question 'What is Wine'. The Gimp's web site (http://www.gimp.org/) is a good example in that respect. The first paragraph of the page answers the question 'What is the GIMP?'.
Thus I think there should be a link to the News page but no more. The news page is for returning visitors and if that's what they care about then they should bookmark that page rather than the home page.
I think nobody does that. Whenever *I* visit a page, I'm visiting it in order to know the latest facts about a project. And let's face it, there are only so many n00bs compared to long-time Wine users. I'd be willing to bet that 60% of WineHQ traffic is caused by long-time Wine users, and the rest is newbies. And what long-time users want is *news*.
Other things I have now realized:
- I said before I prefered a non-expanded menu (again, ala Gimp) to a
fully expanded one. Now I changed my mind. If the menu is not fully expanded from the start then it's hard to figure out what the heck is in the unexpanded items. Proof: the current WineHQ site. Other proof, The Gimp's web site. Click on Documentation. Wow! Eleven items appear! Before expanding the menu, did you know that mailing list was in Documentation rather than in Resources? No? Well, you had no way of knowing anyway.
True. IMHO we should try to have two levels by default, and a third hidden level if need be (on the resulting page).
- That brings me to another point. I like the menus in Bugzilla and the
Application Database: http://wine.codeweavers.com/bugs/ http://appdb.winehq.com/ I vote for using the same system for WineHQ. This would also bring a better unity of style. Each top-level menu is a 'box' that contains all the level two menu items.
Sounds good (if it's doable).
- Who cares about an 'Applications Database'? What's that anyway?
Would a potential Wine user want to have dealings with a database? Nah. Must be for geeks. What users want to know is what applications run in Wine and thus that's how the menu entry and the thing itself should be called: 'Supported Applications'. Even if the truth is that it lists applications that do not work too.
True. Application Database is somewhat non-descriptive. Well, why not call its item "(Non-)Supported Applications" then ? ;-)
- I'm moving the Who's Who to the development section. Now it seems
clear to me that people trying to have an idea about what Wine is don't care about Who's Who. On the other hand, developpers, i.e. people more involved with the project, would certainly be interested to know more about their fellow developpers (in fact it's almost a developper list).
No, it's a developer list ;-)
- Contributing is important. I'm glad Dimitrie agrees with me. But now
I'm not sure we should have a menu entry for each of its sections. So I moved it to 'About Wine'. This means it gets nearer where people new to Wine (i.e. who are not involved in Wine yet) are. Maybe that compensates a bit...
I think that that one *at least* also needs a link on the Development section if we don't have a separate Contributing section.
- In the same spirit there are things that must be there but that fewer
people would look for. So I created a 'Misc' top-level section which would be the last section to regroup these and unclutter more important sections such as 'About Wine'. As a guiding principle I tried to imagine someone new to Wine who is not a developper, determine what he will want to see first, and put these first. Then come potential developpers but I know they will zoom in on the 'Development' and 'Forums' categories and go there.
So, here goes:
Home (no menu item for this one, just click on the Wine logo)
About Wine 1.1. Introduction a. Intro b. Why Wine c. Myths d. Technology e. History g. Companies 1.2. Screenshots 1.3. Supported Applications 1.4. Contributing a. Application maintainer b. Bug triage c. Website maintenance d. Development 1.5. News 1.6. Press
Download 2.1. Binaries (installing from binaries) 2.2. Source (installing from source) 2.3. CVS (installing from CVS)
Support 3.1. FAQ 3.2. Howto 3.3. Bug Tracking 3.4. Troubleshooting 3.5. Forums a. Mailing Lists b. Newsgroup c. IRC Channel
Documentation 4.1. User Guide 4.2. Developer Guide 4.3. Packager Guide 4.4. API Docs
Development 5.1. Developer Hints 5.2. Submitting Patches 5.3. TODO Lists - 0.9/1.0 TODOs - Tasklist/bug 395 - FIXMEs/bug 455, - Tasklets/bug 406 - most wanted bugs 5.4. Status 5.5. Resources a. LXR b. CVS Web c. Who's Who d. Tools e. Win32 Documentation, X doc, etc.
Miscellaneous 6.1. Community 6.2. Related projects 6.3. Contacts 6.4. Legal
Hmm, (almost) everything ok so far, but can't we do away with Misc ? Misc is so horribly non-descriptive. IMHO as last entry, it might be better to have "The Wine Team", which then includes Community, Contacts and Legal. I'm not sure yet about where to put Related Projects (probably About would be best), but apart from that...
I'm prepared to see my comments ripped to shreds ;-)
Andi
On November 3, 2002 09:24 am, Andreas Mohr wrote:
I'm prepared to see my comments ripped to shreds ;-)
It _is_ a bloody tough thread, isn't it? :)
I think the home page should be targeted to people who may not know what Wine is. Thus it should *answer* the question 'What is Wine'. The Gimp's web site (http://www.gimp.org/) is a good example in that respect. The first paragraph of the page answers the question 'What is the GIMP?'.
I agree with this; our navigation system right now, while pretty, honestly takes up more real estate than it needs to.
Thus I think there should be a link to the News page but no more. The news page is for returning visitors and if that's what they care about then they should bookmark that page rather than the home page.
Here, I disagree. I think having a short news box, as we have now, gives people a sense of what's going on right now with the project, and gives a sense of vitality.
[snip]
- That brings me to another point. I like the menus in Bugzilla and the
Application Database: http://wine.codeweavers.com/bugs/ http://appdb.winehq.com/ I vote for using the same system for WineHQ. This would also bring a better unity of style. Each top-level menu is a 'box' that contains all the level two menu items.
And if we switched to this style, we could unify the appdb and bugzilla looks and it would be a consistent style...
- Who cares about an 'Applications Database'? What's that anyway?
Would a potential Wine user want to have dealings with a database? Nah. Must be for geeks. What users want to know is what applications run in Wine and thus that's how the menu entry and the thing itself should be called: 'Supported Applications'. Even if the truth is that it lists applications that do not work too.
Nice change.
So, here goes:
Home (no menu item for this one, just click on the Wine logo)
About Wine 1.1. Introduction a. Intro b. Why Wine c. Myths d. Technology e. History g. Companies 1.2. Screenshots 1.3. Supported Applications 1.4. Contributing a. Application maintainer b. Bug triage c. Website maintenance d. Development 1.5. News 1.6. Press
Download 2.1. Binaries (installing from binaries) 2.2. Source (installing from source) 2.3. CVS (installing from CVS)
Support 3.1. FAQ 3.2. Howto 3.3. Bug Tracking 3.4. Troubleshooting 3.5. Forums a. Mailing Lists b. Newsgroup c. IRC Channel
Documentation 4.1. User Guide 4.2. Developer Guide 4.3. Packager Guide 4.4. API Docs
Development 5.1. Developer Hints 5.2. Submitting Patches 5.3. TODO Lists - 0.9/1.0 TODOs - Tasklist/bug 395 - FIXMEs/bug 455, - Tasklets/bug 406 - most wanted bugs 5.4. Status 5.5. Resources a. LXR b. CVS Web c. Who's Who d. Tools e. Win32 Documentation, X doc, etc.
Miscellaneous 6.1. Community 6.2. Related projects 6.3. Contacts 6.4. Legal
'Just' 33 menu items (down from 44 for both Dimitrie's and Jeremy's proposals). WineHQ is a big site... Hopefully there's not too much hiding.
I like this quite a bit; however, I still feel that #6 should be "Community"; Contacts and Legal can easily be moved to small footnotes on the top level page and/or the About page.
Just having a 'Misc' category makes my skin crawl, because it always seems like the web designer couldn't be bothere to think something through.
One other issue: if we do switch to an app db style of navigation, then we're going to need a lot of content to fill in items (iow, we're going to need stuff to fill in for 2.a, 3.a, 4.a, and so on).
Jer
On November 3, 2002 05:28 am, Francois Gouget wrote:
- having a fully expanded menu means we must have fewer items otherwise
it risks being overwhelming. Things are not as bad as they seem because in my proposal I tried to include every item currently in the web site and I gave it a place in the hierarchy. But some of these items should not have a menu entry for themselves but just be a section on a page.
This is the crux of the matter. If we go for fully expanded menus, they all become "top-level"/one click, and the way you organize them is not that important anymore. So, I like your proposal, I think its the way to go.
That being said I have a few items where I want to comment on (in order of importance):
* I am with Jer, Andy, and Igor that News has to go on the first page. There are many reasons why this is so, but most important, it's current practice, and as I said, the burdon of proof it's on you to do away with it :). But let me list a few reasons here: -- a person reads the "About" section *on time*. Once that's done s/he is interested in News. -- even before reading the "About" most people want to get an idea if the project is still alive, so they don't waste time going through all the info. There's no better way then with a News section that's visible first hand -- If you visit the site more than once (which everybody that we aim the site for will do), it becomes sooo tiring to see the same old information over, and over, and over, again. Gimp was doing that, and I *hate* it. I was so glad to see them add the news section on the Home. * I also hate the term "Application Database". It sounds too techy, and it's one of the reasons I never used it. So I suggest "Application Status" * The "Supported Applications" idea is a good one, and I've been advocating it for a few days now. This should be a hand-maintained list of apps what we have 'officially' tested, and know for a fact that work decently in Wine. See the current efforts to come up with the Gold list of apps supported under Wine. * Minor nit, but I still don't like CVS under Downloads. First off, nobody thinks about using CVS as a Download option. There is a big semantical impedance mismatch here. CVS is viewed as a development tool. Also people using CVS don't go to Download, and viceversa. I think it's a mistake to group items based on their form/syntax, rather than meaning/semantics. In this case, the grouping is based on the fact that there are bits going across the wire, and I don't feel it's a meaningful distinction for anyone. * I think the header boxes for the menu (what used to be top-level before, like Development, About, etc.) should not be clickable. It's a minor nit, but if we go to fully expanded items, they don't 'feel' like a menu, but a heading. This goes to the About/Intro discussion. * Something to keep in mind: the App DB menus don't render properly in Konqy. If we're gonna standardize on that format, we should make sure they render correctly in the OSS-world browsers.
I suggest we work off of your latest proposal, and suggest 'patches' to it, if anyone feels there should be changes. But this does seem to bring us closer to a universally accepted solution. Yay!
- The "Supported Applications" idea is a good one, and I've been advocating it for a few days now. This should be a hand-maintained list of apps what we have 'officially' tested, and know for a fact that work decently in Wine. See the current efforts to come up with the Gold list of apps supported under Wine.
I actually think that we could have exactly one entry - and that it be called 'Supported Applications'. That's the link people will click on; it addresses their immediate question. Trying to be more semantically precise with the main menu link is a mistake, imo.
- Minor nit, but I still don't like CVS under Downloads. First off, nobody thinks about using CVS as a Download option. There is a big semantical impedance mismatch here. CVS is viewed as a development tool. Also people using CVS don't go to Download, and viceversa. I think it's a mistake to group items based on their form/syntax, rather than meaning/semantics. In this case, the grouping is based on the fact that there are bits going across the wire, and I don't feel it's a meaningful distinction for anyone.
I disagree here. I don't think we should expound on CVS here, I'm just thinking a link to the detailed instructions under Development. What's the first thing a newbie gets told after reporting a problem: "Have you tried it against the CVS tip?"
I suggest we work off of your latest proposal, and suggest 'patches' to it, if anyone feels there should be changes. But this does seem to bring us closer to a universally accepted solution. Yay!
I'm good with that. Double yay!
On November 3, 2002 12:11 pm, Jeremy White wrote:
I actually think that we could have exactly one entry - andthat it be called 'Supported Applications'. That's the link people will click on; it addresses their immediate question. Trying to be more semantically precise with the main menu link is a mistake, imo.
I am not sure what you're saying here, but as far as I'm concerned, I think we should have a link in the menu *only* to the Supported Applications page (the hand written one), and from there a link to the Application Database. If this is what you're saying, I agree. If you are saying that we should point people directly to the Application Database, I disagree.
I disagree here. I don't think we should expound on CVS here, I'm just thinking a link to the detailed instructions under Development. What's the first thing a newbie gets told after reporting a problem: "Have you tried it against the CVS tip?"
But this is meaningless duplication. All menus are visible on the screen, so there is no point in having two CVS links on the main page. In order to use the latest CVS, you better know you're dealing with Development stuff, so I still think it belongs under Development. In fact, current practice is to put CVS stuff under development, and _NOT_ download. Look at SourceForge, and a gazillion other sites. And as I said, I think there are good reasons for doing it. And BTW, even if there not, many times it's better to stay with the accepted practice in things of these nature.
Hey, are these the only points of disagreement?!?!? :)
I am not sure what you're saying here, but as far as I'm concerned, I think we should have a link in the menu *only* to the Supported Applications page (the hand written one), and from there a link to the Application Database. If this is what you're saying, I agree. If you are saying that we should point people directly to the Application Database, I disagree.
I'm advocating that the main menu link be called 'Supported Applications', and I'm reserving judgement on what the resulting page looks like. However, I think your suggestion is fine, so long as the app db is not buried as far as you would seem to like it.
[snip]
But this is meaningless duplication. All menus are visible on the screen, so there is no point in having two CVS links on the main page. In order to use the latest CVS, you better know you're dealing with Development stuff, so I still think it belongs under Development. In fact, current practice is to put CVS stuff under development, and _NOT_ download. Look at SourceForge, and a gazillion other sites. And as I said, I think there are good reasons for doing it. And BTW, even if there not, many times it's better to stay with the accepted practice in things of these nature.
Yikes. I hadn't understood that the whole menu tree would be visible on the main page. I don't like that at all. 34 choices on the first page is way more than the 7 max I advocate...
Jer
On November 3, 2002 12:38 pm, Jeremy White wrote:
I'm advocating that the main menu link be called 'Supported Applications', and I'm reserving judgement on what the resulting page looks like. However, I think your suggestion is fine, so long as the app db is not buried as far as you would seem to like it.
No, I don't want to bury the app db. All I'm saying is that we should have a nice, hand-crafted page saying we support these apps, give them a start ratings, links to where they can be downloaded (if applicable), maybe links to a screenshot or two, etc.
On that page, somewhere visible, we should put a link to the database, saying: for more information on the support status of other apps, please visit our community maintained application database. Or something along the line.
On November 3, 2002 12:38 pm, Jeremy White wrote:
Yikes. I hadn't understood that the whole menu tree would be visible on the main page. I don't like that at all. 34 choices on the first page is way more than the 7 max I advocate...
Please look at: http://appdb.winehq.com/ The menus are expanded, aren't they? And I was hoping we all agreed on something, finally. <g>
On Sun, 2002-11-03 at 11:50, Dimitrie O. Paun wrote:
On November 3, 2002 12:38 pm, Jeremy White wrote:
Yikes. I hadn't understood that the whole menu tree would be visible on the main page. I don't like that at all. 34 choices on the first page is way more than the 7 max I advocate...
Please look at: http://appdb.winehq.com/ The menus are expanded, aren't they? And I was hoping we all agreed on something, finally. <g>
But the menus only have 7 main choices, and clicking most of them bring up submenus in the main page (which is, on reflection, probably not optimal).
My understanding was that we were going to use a primary/secondary menu design. The best example of this I know is www.pack223.org (my son's cub scout pack web site *blush*).
You choose an entry from the main menu, and you get a secondary menu on the sidebar. It is like the Gimp, only the menus don't expand in place. The primary menu is constant; the secondary menu varies depending on where you are in the navigation.
Jer
On Sunday 03 November 2002 02:52 pm, Jeremy White wrote:
On Sun, 2002-11-03 at 11:50, Dimitrie O. Paun wrote:
On November 3, 2002 12:38 pm, Jeremy White wrote:
Yikes. I hadn't understood that the whole menu tree would be visible on the main page. I don't like that at all. 34 choices on the first page is way more than the 7 max I advocate...
Please look at: http://appdb.winehq.com/ The menus are expanded, aren't they? And I was hoping we all agreed on something, finally. <g>
But the menus only have 7 main choices, and clicking most of them bring up submenus in the main page (which is, on reflection, probably not optimal).
My understanding was that we were going to use a primary/secondary menu design. The best example of this I know is www.pack223.org (my son's cub scout pack web site *blush*).
You choose an entry from the main menu, and you get a secondary menu on the sidebar. It is like the Gimp, only the menus don't expand in place. The primary menu is constant; the secondary menu varies depending on where you are in the navigation.
Can we also use some javascript/dhtml to create pop-out menus? If they are well-designed they can be much easier to navigate than by clicking on stuff. I'm sure we could get it to work with Mozilla, Netscape, MSIE, and standards-compliant browsers, and the rest can use a static interface.
On November 3, 2002 03:52 pm, Jeremy White wrote:
But the menus only have 7 main choices, and clicking most of them bring up submenus in the main page (which is, on reflection, probably not optimal).
Well, I say, let's get the expanded menu a chance. It solves a few problems quite nicely, and it may not be too bad.
If we have to hide the submenus, we will have to reopen the discussions about which items make it on top. Somehow, I don't feel it's a good idea right now. :)
On November 3, 2002 05:04 pm, Dimitrie O. Paun wrote:
Well, I say, let's get the expanded menu a chance. It solves a few problems quite nicely, and it may not be too bad.
sigh: s/get/give/
On Sunday 03 November 2002 11:38 am, Jeremy White wrote:
I am not sure what you're saying here, but as far as I'm concerned, I think we should have a link in the menu *only* to the Supported Applications page (the hand written one), and from there a link to the Application Database. If this is what you're saying, I agree. If you are saying that we should point people directly to the Application Database, I disagree.
I'm advocating that the main menu link be called 'Supported Applications', and I'm reserving judgement on what the resulting page looks like. However, I think your suggestion is fine, so long as the app db is not buried as far as you would seem to like it.
[snip]
But this is meaningless duplication. All menus are visible on the screen, so there is no point in having two CVS links on the main page. In order to use the latest CVS, you better know you're dealing with Development stuff, so I still think it belongs under Development. In fact, current practice is to put CVS stuff under development, and _NOT_ download. Look at SourceForge, and a gazillion other sites. And as I said, I think there are good reasons for doing it. And BTW, even if there not, many times it's better to stay with the accepted practice in things of these nature.
Yikes. I hadn't understood that the whole menu tree would be visible on the main page. I don't like that at all. 34 choices on the first page is way more than the 7 max I advocate...
Actually, if it is well-designed, it can be very nice. Keep in mind that you can use things like bold text and indenting to emphasize the major categories and individual pages. You would understand the structure instantly, without guessing. I don't see why every page should have no more than 7 links. Most people aren't dyslexic, and I don't think that choosing the page you want from a well-grouped list is difficult. In fact, it would be easier because you wouldn't have to guess in which category the page might be located. In some situations that would be the case.
On Sunday 03 November 2002 11:11 am, Jeremy White wrote:
- The "Supported Applications" idea is a good one, and I've been advocating it for a few days now. This should be a hand-maintained list of apps what we have 'officially' tested, and know for a fact that work decently in Wine. See the current efforts to come up with the Gold list of apps supported under Wine.
I actually think that we could have exactly one entry - andthat it be called 'Supported Applications'. That's the link people will click on; it addresses their immediate question. Trying to be more semantically precise with the main menu link is a mistake, imo.
Agreed. "Supported Apps" makes sense and conveys the exact purpose of the app database. "Application Progress Status" that someone suggested sounds weird and is far worse than "Application Database". We don't need to be semantically correct, these are people we are talking to, not a compiler.
- Minor nit, but I still don't like CVS under Downloads. First off, nobody thinks about using CVS as a Download option. There is a big semantical impedance mismatch here. CVS is viewed as a development tool. Also people using CVS don't go to Download, and viceversa. I think it's a mistake to group items based on their form/syntax, rather than meaning/semantics. In this case, the grouping is based on the fact that there are bits going across the wire, and I don't feel it's a meaningful distinction for anyone.
I disagree here. I don't think we should expound on CVS here, I'm just thinking a link to the detailed instructions under Development. What's the first thing a newbie gets told after reporting a problem: "Have you tried it against the CVS tip?"
Just having a link to the cvs instructions is good. It doesn't clutter stuff up. How about separating stuff into three sections: - source/binary packages (RPM/deb) - source snapshot - cvs
You could have links in the first two and a link to the detailed instructions in the third. Doesn't clutter stuff up and does not confuse newbies. Something along the lines of "If you want to develop wine and you want the bleeding edge stuff, click here for the cvs instructions".
I suggest we work off of your latest proposal, and suggest 'patches' to it, if anyone feels there should be changes. But this does seem to bring us closer to a universally accepted solution. Yay!
I'm good with that. Double yay!
Cool.
On Sun, Nov 03, 2002 at 11:36:36AM -0500, Dimitrie O. Paun wrote:
On November 3, 2002 05:28 am, Francois Gouget wrote:
- I also hate the term "Application Database". It sounds too techy, and it's one of the reasons I never used it. So I suggest
"Application Status"
That's good, too.
- Minor nit, but I still don't like CVS under Downloads. First off, nobody thinks about using CVS as a Download option. There is a big semantical impedance mismatch here. CVS is viewed as a development tool. Also people using CVS don't go to Download, and viceversa. I think it's a mistake to group items based on their form/syntax, rather than meaning/semantics. In this case, the grouping is based on the fact that there are bits going across the wire, and I don't feel it's a meaningful distinction for anyone.
IMHO the CVS stuff should *only* be mentioned in the Wine User Guide (and the Developers Guide would explain the more advanced usage patterns). Then it'd be pretty easy to simply add a small "For CVS download of Wine source, see <Wine Users Guide link>". As the Wine Users Guide would have a link to the Wine Developers Guide for advanced stuff on its own, you even wouldn't need to mention the Wine Devel Guide CVS link, too...
- Something to keep in mind: the App DB menus don't render properly in Konqy. If we're gonna standardize on that format, we should make sure they render correctly in the OSS-world browsers.
Bad, bad Konqy again ;) Good point, though.
I suggest we work off of your latest proposal, and suggest 'patches' to it, if anyone feels there should be changes. But this does seem to bring us closer to a universally accepted solution. Yay!
Hmm, could someone yell "me!" when it comes to finding someone to mail a "this is it so far" status report to wine-devel ? I think it'd be good to have a mail describing the current agreement. And no, I won't do it, since I've got way too many things to do in the less than 2 hours left until my departure.
On November 3, 2002 12:26 pm, Andreas Mohr wrote:
IMHO the CVS stuff should *only* be mentioned in the Wine User Guide (and the Developers Guide would explain the more advanced usage patterns). Then it'd be pretty easy to simply add a small "For CVS download of Wine source, see <Wine Users Guide link>".
Why in Wine User Guide? Ideally, users should not have to deal with CVS at all. The *only* reason this is so it's that Wine is very immature, and changes quickly. But once we reach a stable release, this should hopefully change a little. When I open the user guide, I want it to small, and to the point -- it has to tell me the absolute minimum that I need to know to run the thing. Note: ideally, it should be so easy, and intuitive to run Wine, that we should not need a Wine User Guide!
Hmm, could someone yell "me!" when it comes to finding someone to mail a "this is it so far" status report to wine-devel ? I think it'd be good to have a mail describing the current agreement.
It will get done, give people a day, or two to comment on it. I'll do it if need be, don't worry. But the point is well taken: summarizing the results of such threads is very imporantant, as otherwise we loose a lot of the good stuff hidden in the middle of long emails. This is the very reason I sent in my proposal for the menu, as it was a kind of summarization of the discussions we had around here.
On Sun, Nov 03, 2002 at 12:41:29PM -0500, Dimitrie O. Paun wrote:
On November 3, 2002 12:26 pm, Andreas Mohr wrote:
IMHO the CVS stuff should *only* be mentioned in the Wine User Guide (and the Developers Guide would explain the more advanced usage patterns). Then it'd be pretty easy to simply add a small "For CVS download of Wine source, see <Wine Users Guide link>".
Why in Wine User Guide? Ideally, users should not have to deal with CVS at all. The *only* reason this is so it's that Wine is very immature, and changes quickly. But once we reach a stable release, this should hopefully change a little. When I open the user guide, I want it to small, and to the point -- it has to tell me the absolute minimum that I need to know to run the thing. Note: ideally, it should be so easy, and intuitive to run Wine, that we should not need a Wine User Guide!
Hmm, I guess you're right. How about we throw away CVS in User Guide and document *all* CVS management issues in the Devel Guide and simply have a reference to the Devel Guide in the Users Guide when it comes to CVS ? WineHQ would then use a link to the Devel Guide only, of course. I think that makes quite some sense.
On November 3, 2002 12:51 pm, Andreas Mohr wrote:
Hmm, I guess you're right. How about we throw away CVS in User Guide and document *all* CVS management issues in the Devel Guide and simply have a reference to the Devel Guide in the Users Guide when it comes to CVS ? WineHQ would then use a link to the Devel Guide only, of course. I think that makes quite some sense.
Sounds good to me. In fact, I like it lots. Any takers? :)
On Sunday 03 November 2002 11:41 am, Dimitrie O. Paun wrote:
On November 3, 2002 12:26 pm, Andreas Mohr wrote:
IMHO the CVS stuff should *only* be mentioned in the Wine User Guide (and the Developers Guide would explain the more advanced usage patterns). Then it'd be pretty easy to simply add a small "For CVS download of Wine source, see <Wine Users Guide link>".
Why in Wine User Guide? Ideally, users should not have to deal with CVS at all. The *only* reason this is so it's that Wine is very immature, and changes quickly. But once we reach a stable release, this should hopefully change a little. When I open the user guide, I want it to small, and to the point -- it has to tell me the absolute minimum that I need to know to run the thing. Note: ideally, it should be so easy, and intuitive to run Wine, that we should not need a Wine User Guide!
A stable release is years in the future. When it happens, many people will offer to redesign the website. Until them, let's focus on what Wine is now and not what it will become in 5 years.
Hmm, could someone yell "me!" when it comes to finding someone to mail a "this is it so far" status report to wine-devel ? I think it'd be good to have a mail describing the current agreement.
It will get done, give people a day, or two to comment on it. I'll do it if need be, don't worry. But the point is well taken: summarizing the results of such threads is very imporantant, as otherwise we loose a lot of the good stuff hidden in the middle of long emails. This is the very reason I sent in my proposal for the menu, as it was a kind of summarization of the discussions we had around here.
Ummm... the whole patch idea seems pretty stupid. Let's agree on a plan and let one person do everything. Website development by committee is not going to work well, especially since we are in need of a new design (and not simply some updating).
I wouldn't mind working on a redesigned version, as long as I don't have to do it in small incremental patches that get endlessly discussed on wine-devel. Does anyone really know how the website is structured currently? Does it run out of a database? If not, what does it use PHP for? Can we make it mostly-static or is it some weird system that requires tons of scripting? I know php, but it should be easy to maintain for someone who doesn't.
On November 3, 2002 01:03 pm, Igor Izyumin wrote:
Ummm... the whole patch idea seems pretty stupid. Let's agree on a plan and let one person do everything. Website development by committee is not going to work well, especially since we are in need of a new design (and not simply some updating).
Well, I wasn't clean: I mean patch in the abstract meaning. That is, the mail are getting large, and I don't want people to post another 35 item menu to suggest we rename A to B. That's it, nothing to fancy. And at the end of the day, it's obvious someone should gather all these suggestions, make some decisions, and give us the fscking menu, right? What's stupid in that?
I wouldn't mind working on a redesigned version, as long as I don't have to do it in small incremental patches that get endlessly discussed on wine-devel. Does anyone really know how the website is structured currently? Does it run out of a database? If not, what does it use PHP for? Can we make it mostly-static or is it some weird system that requires tons of scripting? I know php, but it should be easy to maintain for someone who doesn't.
I'm 100% with you here. All this fancy technology for what? WineHQ is static content, why get fancy with that? In my experience, it's not worth it, but we should allow the webmaster to pick his tools. It's his prerogative.
--- Francois Gouget fgouget@free.fr wrote:
I like this but with a couple tweaks:
Home (no menu item for this one, just click on the Wine logo)
- About Wine 1.1. Introduction a. Intro b. Why Wine c. Myths d. Technology e. History g. Companies 1.2. Screenshots 1.3. Supported Applications
These 2 should be compined, list-like...
1.2 Supported Applications/Screenshots
On that page 2 links for each app, Click on the app name and it tells the status of that app, and a link saying "Screenshots!" right next to the App name...
1.4. Contributing a. Application maintainer b. Bug triage c. Website maintenance d. Development 1.5. News 1.6. Press
Download 2.1. Binaries (installing from binaries) 2.2. Source (installing from source) 2.3. CVS (installing from CVS)
Support 3.1. FAQ 3.2. Howto 3.3. Bug Tracking 3.4. Troubleshooting 3.5. Forums a. Mailing Lists b. Newsgroup c. IRC Channel
Documentation 4.1. User Guide 4.2. Developer Guide 4.3. Packager Guide 4.4. API Docs
Development 5.1. Developer Hints 5.2. Submitting Patches 5.3. TODO Lists - 0.9/1.0 TODOs - Tasklist/bug 395 - FIXMEs/bug 455, - Tasklets/bug 406 - most wanted bugs 5.4. Status 5.5. Resources a. LXR b. CVS Web c. Who's Who d. Tools e. Win32 Documentation, X doc, etc.
Miscellaneous 6.1. Community 6.2. Related projects 6.3. Contacts 6.4. Legal
Cross-link Contacts to the Who's Who and include emails for the developers in the Who's Who... Put CVS Web under Misc as it is more of a feature than an essential part of development...
'Just' 33 menu items (down from 44 for both Dimitrie's and Jeremy's proposals). WineHQ is a big site... Hopefully there's not too much hiding.
We should also make it kinda like the REALLY old WinAmp site (and native regedit) where you have each item with a + icon to expand and collapse the tree, i guess its also like the MSDN web site...
-Dustin
__________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
-
Andreas Mohr -
Chris Morgan -
Dimitrie O. Paun -
Dustin Navea -
Francois Gouget -
Igor Izyumin -
Jeremy White