Re: My WineHQ menu structure proposal - counterproposal
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). [...] 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 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. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.
Re: My WineHQ menu structure proposal
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 [EMAIL PROTECTED] 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. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.
Re: My WineHQ menu structure proposal - counterproposal
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. -- Dimi.
Re: My WineHQ menu structure proposal - counterproposal
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) -- Dimi.
Re: My WineHQ menu structure proposal - counterproposal
On Sun, Nov 03, 2002 at 09:43:40AM +, Keith Matthews wrote: On 02 Nov 2002 23:51:01 -0600 Jeremy White [EMAIL PROTECTED] wrote: 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. Ugh. Why do people insist on thinking that 'sexy' images are the be-all and end-all of web design. When I go to a web site I want _information_, not some bandwidth-soaking image that gives nothing useful. Have screen-shots for those that can't see beyond them, but don't put them on the home page, put a clear link to them. A lot of people are still on analogue dial-up links, they don't appreciate large images increasing download time, I'm on DSL and I switch off images to get faster downloads. But a screenshot showing a sufficient amount of information should only have about 5 KB or slightly more (I hope :). Also add a subtitle describing the current screenshot, and then 5 KB ought to be enough for everybody to be interested about a particular screenshot. Other than that you may want to promote 'legal' to the top level, if only to reduce the number of menu options for item 1 at the next level. 9 is as many as one should have and 7 is a better limit. Yep, 7 is the standard amount of things you can manage/grasp. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: My WineHQ menu structure proposal
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? -- -- Igor
Re: My WineHQ menu structure proposal - counterproposal
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: 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. 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) -- -- Igor
Re: My WineHQ menu structure proposal - counterproposal
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
Re: My WineHQ menu structure proposal
On Sun, Nov 03, 2002 at 03:07:48PM +, Keith Matthews wrote: On Sun, 3 Nov 2002 15:24:14 +0100 Andreas Mohr [EMAIL PROTECTED] wrote: On Sun, Nov 03, 2002 at 02:28:54AM -0800, Francois Gouget wrote: * 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 ? ;-) This seems to be an area where conciseness and descriptiveness are diametrically opposed. We will probably argue long and hard. My contribution Application Support States. Close, but no whole cigar ;-) I like Application Support Progress somewhat better. (and Progress has a coolness factor associated with it :) Although it's 3 not very short words, so that might disqualify it easily... Hmm, and what about doing away with Support entirely ? Then it'd be usable. 6. 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... Can't say I like 'Misc' either, and I do think that legal should be more visible. The project is getting to be fairly visible to governments and big corporations, and they like to check legalities early on. How about 'Contacts and Legal'. Then you'd expel Community, I think (it wouldn't really fit in there). But of course I'm aware that Legal might not easily get associated with The Wine Team. Hmm, this could still need some improvement... -- My attitude is, everybody should try competing with Microsoft once in their life. Once. - Marc Andreessen, former Netscape lead employee, in a browser wars interview
Re: My WineHQ menu structure proposal - counterproposal
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: 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. 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. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: My WineHQ menu structure proposal
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 - 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. 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. -- -- Igor
Re: My WineHQ menu structure proposal
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! -- Dimi.
Re: My WineHQ menu structure proposal
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. -- -- Igor
Re: My WineHQ menu structure proposal
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? :) -- Dimi.
Re: My WineHQ menu structure proposal
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. -- -- Igor
Re: My WineHQ menu structure proposal
On November 3, 2002 12:11 pm, Jeremy White wrote: 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. 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?!?!? :) -- Dimi.
Re: My WineHQ menu structure proposal
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.
Re: My WineHQ menu structure proposal
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
Re: My WineHQ menu structure proposal
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? :) -- Dimi.
Re: My WineHQ menu structure proposal
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. -- Dimi.
Re: My WineHQ menu structure proposal
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.
Re: My WineHQ menu structure proposal
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. -- Dimi.
Re: My WineHQ menu structure proposal
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 -- Dimi.
Re: My WineHQ menu structure proposal
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
Re: My WineHQ menu structure proposal
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. -- -- Igor
Re: My WineHQ menu structure proposal
--- Igor Izyumin [EMAIL PROTECTED] 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/
Re: My WineHQ menu structure proposal
--- Francois Gouget [EMAIL PROTECTED] wrote: I like this but with a couple tweaks: 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 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 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 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/
Re: My WineHQ menu structure proposal - counterproposal
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 Andreasg. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS
Re: My WineHQ menu structure proposal
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. :) -- Dimi.
Re: My WineHQ menu structure proposal
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/ -- Dimi.
Re: My WineHQ menu structure proposal
* 607 - Add screenshots Where would screenshots be contributed to? Mailed to wine-devel? Appended to the bug entry in bugzilla? Chris
Re: My WineHQ menu structure proposal
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. -- Dimi.
Re: My WineHQ menu structure proposal
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
Re: My WineHQ menu structure proposal - counterproposal
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
