Re: menu structure
Cheers, Konrad (off for lunch to Quantum) Way late, but... was that the restaurant at KTH, Stockholm? /Christian -- Christian Ridderström, +46-8-768 39 44http://www.md.kth.se/~chr
Re: menu structure
Christian Ridderström wrote: Cheers, Konrad (off for lunch to Quantum) Way late, but... was that the restaurant at KTH, Stockholm? Indeed. I am still at S3. /Konrad
[O-T]: Re: menu structure
On Sun, 16 Nov 2008, Konrad Hofbauer wrote: Christian Ridderström wrote: Cheers, Konrad (off for lunch to Quantum) Way late, but... was that the restaurant at KTH, Stockholm? Indeed. I am still at S3. Small world (I did my PhD there). Wonder how LyX users there are at KTH these days. /C -- Christian Ridderström, +46-8-768 39 44http://www.md.kth.se/~chr
Re: menu structure
Cheers, Konrad (off for lunch to Quantum) Way late, but... was that the restaurant at KTH, Stockholm? /Christian -- Christian Ridderström, +46-8-768 39 44http://www.md.kth.se/~chr
Re: menu structure
Christian Ridderström wrote: Cheers, Konrad (off for lunch to Quantum) Way late, but... was that the restaurant at KTH, Stockholm? Indeed. I am still at S3. /Konrad
[O-T]: Re: menu structure
On Sun, 16 Nov 2008, Konrad Hofbauer wrote: Christian Ridderström wrote: > Cheers, > Konrad (off for lunch to Quantum) Way late, but... was that the restaurant at KTH, Stockholm? Indeed. I am still at S3. Small world (I did my PhD there). Wonder how LyX users there are at KTH these days. /C -- Christian Ridderström, +46-8-768 39 44http://www.md.kth.se/~chr
Re: menu structure
Christian Ridderström wrote: Having said the above and sounding negative, No, not at all!!! A different perspective ... I think it's great that you are looking at menu structure in a structured way! I (sort of) came to the conclusion though that it is too late for 1.6 anyhow (especially in terms of documentation). Am I right with that? /Konrad
Re: menu structure
On Fri, 26 Sep 2008, Konrad Hofbauer wrote: I (sort of) came to the conclusion though that it is too late for 1.6 anyhow (especially in terms of documentation). Am I right with that? No idea about that, but the documentation could certainly be an issue. In general, I think we should be careful about changing the menu structure, and also that we should have good reasons for the changes. In a perfect world, we'd even document _why_ we do the changes. I haven't followed this thread, so the following idea has probably already been raised, but just in case it hasn't: I think it'd be a good idea to ask users for feedback on the menu structure. Maybe by releasing a separate version of LyX so that users can actually test it. Or by presenting the structures (old, new1, new2 etc) to a wider range of users as menu trees or something. If it's only a matter of changing the menu configuration file[*], you could publish that file on the users' list and ask for feedback. Best regards /Christian [*] Is it only the menu configuration file that needs changing? -- Christian Ridderström, +46-8-768 39 44http://www.md.kth.se/~chr
Re: menu structure
Christian Ridderström wrote: On Fri, 26 Sep 2008, Konrad Hofbauer wrote: I (sort of) came to the conclusion though that it is too late for 1.6 anyhow (especially in terms of documentation). Am I right with that? No idea about that, but the documentation could certainly be an issue. In general, I think we should be careful about changing the menu structure, and also that we should have good reasons for the changes. In a perfect world, we'd even document _why_ we do the changes. It will need a VERY detailed WHY, to get any approval/consensus even here on the devel-list, only. I haven't followed this thread, so the following idea has probably already been raised, but just in case it hasn't: I think it'd be a good idea to ask users for feedback on the menu structure. Indeed. Maybe by releasing a separate version of LyX so that users can actually test it. Or by presenting the structures (old, new1, new2 etc) to a wider range of users as menu trees or something. If it's only a matter of changing the menu configuration file[*], you could publish that file on the users' list and ask for feedback. Yes. It only needs change of the menu configuration file, so we could do that. (Hmm... some things are hard-coded though, I believe.) Cheers, Konrad (off for lunch to Quantum)
Re: menu structure
Christian Ridderström wrote: Having said the above and sounding negative, No, not at all!!! A different perspective ... I think it's great that you are looking at menu structure in a structured way! I (sort of) came to the conclusion though that it is too late for 1.6 anyhow (especially in terms of documentation). Am I right with that? /Konrad
Re: menu structure
On Fri, 26 Sep 2008, Konrad Hofbauer wrote: I (sort of) came to the conclusion though that it is too late for 1.6 anyhow (especially in terms of documentation). Am I right with that? No idea about that, but the documentation could certainly be an issue. In general, I think we should be careful about changing the menu structure, and also that we should have good reasons for the changes. In a perfect world, we'd even document _why_ we do the changes. I haven't followed this thread, so the following idea has probably already been raised, but just in case it hasn't: I think it'd be a good idea to ask users for feedback on the menu structure. Maybe by releasing a separate "version" of LyX so that users can actually test it. Or by presenting the structures (old, new1, new2 etc) to a wider range of users as menu trees or something. If it's only a matter of changing the menu configuration file[*], you could publish that file on the users' list and ask for feedback. Best regards /Christian [*] Is it only the menu configuration file that needs changing? -- Christian Ridderström, +46-8-768 39 44http://www.md.kth.se/~chr
Re: menu structure
Christian Ridderström wrote: On Fri, 26 Sep 2008, Konrad Hofbauer wrote: I (sort of) came to the conclusion though that it is too late for 1.6 anyhow (especially in terms of documentation). Am I right with that? No idea about that, but the documentation could certainly be an issue. In general, I think we should be careful about changing the menu structure, and also that we should have good reasons for the changes. In a perfect world, we'd even document _why_ we do the changes. It will need a VERY detailed WHY, to get any approval/consensus even here on the devel-list, only. I haven't followed this thread, so the following idea has probably already been raised, but just in case it hasn't: I think it'd be a good idea to ask users for feedback on the menu structure. Indeed. Maybe by releasing a separate "version" of LyX so that users can actually test it. Or by presenting the structures (old, new1, new2 etc) to a wider range of users as menu trees or something. If it's only a matter of changing the menu configuration file[*], you could publish that file on the users' list and ask for feedback. Yes. It only needs change of the menu configuration file, so we could do that. (Hmm... some things are hard-coded though, I believe.) Cheers, Konrad (off for lunch to Quantum)
Re: menu structure
Konrad Hofbauer wrote: Edwin (and others), great thanks for starting to work on this! I have a number of suggestions for changes, strictly based on the HIG [1] (except those sentences starting with IMO). If something is left open by the HIG, I refer to what I assume are applications that well consider the HIG, namely Safari and OmniGroup software (=OG). Unfortunately the HIG do not cover tabbed applications, so I take Safari 3 and Firefox 3 as reference here. Instead of having different ui/inc-files circulating around, I think it makes more sense if you maintain the master version and include from my suggestion what you deem appropriate. OK ??? I go menu-by-menu (in random order), and only talk about the suggested changes (everything else OK). I say in advance that IMO the Document-Menu should disappear. File *** The HIG says (also related to an older discussion): Close should close the active tab (or window if it is the last tab). Add a Close File to close the active file (in all views/windows). [2] And combining this with what Safari (and Firefox) do with regards to tabs, I propose: New Window New Tab New File New From Template ... Open ... Open Recent --- Close Window Close Tab Close File Save Save As ... Save All Revert to Saved --- Import ... (more to this later) Export As ... (more to this later) [3] --- Version Control Compress File (but IMO this should really be IN the document settings) Statistics ... (this is like Properties, or Get Info) --- Print ... Document Settings ... [4] Concerning Import/Export: According to HIG this should rather be a normal Save As / Open-dialogue, with a drop-down-list to select the format to export/import. This is not just a menu change, but would allow the IMO nice feature of being able to specify a file-name / location for exports (see this as wish-list entry). Having something like Export As, where the filename can be specified would be nice, sure. However, export using the same base filename as the LyX file is a very common case, so that ought to be possible still, and with no more keypresses or waiting than today. Bringing up a save dialog with a default filename filled in probably achieves this, but be careful. Dialogs that populate themselves with a list of existing files tends to be rather slow to open when there are lots of files, or when the folder is on some other server. Now, that is necessary when opening, but definitely not when saving/exporting. (Also, many such dialogs are very slow because they use one call to the filesystem and one call to the window system per file existing in the folder. That approach is wrong because it is too slow. Read the entire file list first, which should be no slower than an ls command. Then fill the display quickly, perhaps it can be done with one operation now that everything is in memory. Save as from firefox is totally rotten for example, when there are 20 000 files already. And I don't need to see them at all, just SAVE THIS.) Something to think about if this change is implemented. Helge Hafting
Re: menu structure
Konrad Hofbauer wrote: Jean-Marc Lasgouttes wrote: Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has Properties in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. What is the difference between file and document in the first place ??? A document may consist of several files. For example, the book where each chapter is a file of its own. Document settings matter only for the master document file, when you print/export the book. The chapter files may have their own settings, but they are used only if you print chapter files separately. Also, don't forget the users who have had LyX as their main word processor for a long time. It is the previous version of LyX that matters for us. Not what word does, because we don't use or have word. There are clearly many more word users in the world, but most of them are not going to switch even if the menus match as closely as possible. I am used to LyX, and for me, the File menu is where I find file-related stuff common to all apps. I.e. save/open/new/print/export/import. That's the place where I have to deal with folders and disks. The Document menu is much more application specific. Not all file-oriented apps deal with documents at all. Many do, but in very different ways. This is where I go for layout options like margins, page size and document-wide font setup. This is is where I go for other document-related stuff, like change tracking. Still - some change is ok with me, if it improves LyX. But not just change for change's sake, or in order to follow some principle to the letter. When following a rule strictly make things worse, it just means the rule have (unstated or undiscovered) exceptions. Maybe the outline toggle fits better on the view menu? Its use is very much like the toolbar toggles. Helge Hafting
Re: menu structure
On Thu, 25 Sep 2008, Helge Hafting wrote: Konrad Hofbauer wrote: Jean-Marc Lasgouttes wrote: Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has Properties in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. FWIW, I like having a separate menu for 'document' related issues. I used LyX again quite recently after not having used it for a _long_ time, so long that I'd had time to forget there was a document menu. (Back when I was a regular user, it was so long ago that document settings were somewhere else). However, even me not really being used to the location of the document settings, I found it quickly and it soon felt right. What is the difference between file and document in the first place ??? A document may consist of several files. For example, the book where each chapter is a file of its own. Document settings matter only for the master document file, when you print/export the book. The chapter files may have their own settings, but they are used only if you print chapter files separately. I think Helge makes a very good point here. A file and a document aren't necessarily the same. (FWIW, I did my thesis as a multi-part document as he describes it so the use case isn't that uncommon.) Having said the above and sounding negative, I think it's great that you are looking at menu structure in a structured way! /Christian -- Christian Ridderström, +46-8-768 39 44http://www.md.kth.se/~chr
Re: menu structure
Konrad Hofbauer wrote: Edwin (and others), great thanks for starting to work on this! I have a number of suggestions for changes, strictly based on the HIG [1] (except those sentences starting with IMO). If something is left open by the HIG, I refer to what I assume are applications that well consider the HIG, namely Safari and OmniGroup software (="OG"). Unfortunately the HIG do not cover tabbed applications, so I take Safari 3 and Firefox 3 as reference here. Instead of having different ui/inc-files circulating around, I think it makes more sense if you maintain the "master" version and include from my suggestion what you deem appropriate. OK ??? I go menu-by-menu (in random order), and only talk about the suggested changes (everything else OK). I say in advance that IMO the Document-Menu should disappear. File *** The HIG says (also related to an older discussion): "Close" should close the active tab (or window if it is the last tab). Add a "Close File" to close the active file (in all views/windows). [2] And combining this with what Safari (and Firefox) do with regards to tabs, I propose: New Window New Tab New File New From Template ... Open ... Open Recent > --- Close Window Close Tab Close File Save Save As ... Save All Revert to Saved --- Import ... (more to this later) Export As ... (more to this later) [3] --- Version Control Compress File (but IMO this should really be IN the document settings) Statistics ... (this is like Properties, or Get Info) --- Print ... Document Settings ... [4] Concerning Import/Export: According to HIG this should rather be a normal Save As / Open-dialogue, with a drop-down-list to select the format to export/import. This is not just a menu change, but would allow the IMO nice feature of being able to specify a file-name / location for exports (see this as wish-list entry). Having something like "Export As", where the filename can be specified would be nice, sure. However, export using the same base filename as the LyX file is a very common case, so that ought to be possible still, and with no more keypresses or waiting than today. Bringing up a save dialog with a default filename filled in probably achieves this, but be careful. Dialogs that populate themselves with a list of existing files tends to be rather slow to open when there are lots of files, or when the folder is on some other server. Now, that is necessary when opening, but definitely not when saving/exporting. (Also, many such dialogs are very slow because they use one call to the filesystem and one call to the window system per file existing in the folder. That approach is wrong because it is too slow. Read the entire file list first, which should be no slower than an "ls" command. Then fill the display quickly, perhaps it can be done with one operation now that everything is in memory. "Save as" from firefox is totally rotten for example, when there are 20 000 files already. And I don't need to see them at all, just SAVE THIS.) Something to think about if this change is implemented. Helge Hafting
Re: menu structure
Konrad Hofbauer wrote: Jean-Marc Lasgouttes wrote: Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has "Properties" in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. What is the difference between file and document in the first place ??? A document may consist of several files. For example, the book where each chapter is a file of its own. "Document settings" matter only for the master document file, when you print/export the book. The chapter files may have their own settings, but they are used only if you print chapter files separately. Also, don't forget the users who have had LyX as their main word processor for a long time. It is the previous version of LyX that matters for us. Not what word does, because we don't use or have word. There are clearly many more word users in the world, but most of them are not going to switch even if the menus match as closely as possible. I am used to LyX, and for me, the "File" menu is where I find file-related stuff common to all apps. I.e. save/open/new/print/export/import. That's the place where I have to deal with folders and disks. The "Document" menu is much more application specific. Not all file-oriented apps deal with documents at all. Many do, but in very different ways. This is where I go for layout options like margins, page size and document-wide font setup. This is is where I go for other document-related stuff, like change tracking. Still - some change is ok with me, if it improves LyX. But not just change for change's sake, or in order to follow some principle to the letter. When following a rule strictly make things worse, it just means the rule have (unstated or undiscovered) exceptions. Maybe the "outline" toggle fits better on the view menu? Its use is very much like the toolbar toggles. Helge Hafting
Re: menu structure
On Thu, 25 Sep 2008, Helge Hafting wrote: Konrad Hofbauer wrote: Jean-Marc Lasgouttes wrote: > Can you point to a program where _all_ document-level settings are in > File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has "Properties" in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. FWIW, I like having a separate menu for 'document' related issues. I used LyX again quite recently after not having used it for a _long_ time, so long that I'd had time to forget there was a document menu. (Back when I was a regular user, it was so long ago that document settings were somewhere else). However, even me not really being used to the location of the document settings, I found it quickly and it soon felt "right". What is the difference between file and document in the first place ??? A document may consist of several files. For example, the book where each chapter is a file of its own. "Document settings" matter only for the master document file, when you print/export the book. The chapter files may have their own settings, but they are used only if you print chapter files separately. I think Helge makes a very good point here. A file and a document aren't necessarily the same. (FWIW, I did my thesis as a multi-part document as he describes it so the use case isn't that uncommon.) Having said the above and sounding negative, I think it's great that you are looking at menu structure in a structured way! /Christian -- Christian Ridderström, +46-8-768 39 44http://www.md.kth.se/~chr
Re: menu structure
Konrad Hofbauer [EMAIL PROTECTED] writes: And my impression from the earlier thread was that we should build something based on HIGs, e.g., JMarc: the menu structure should be done after looking at as many HIG and good quality mainstream programs as possible. JMarc again: We cannot discuss on preferences, only on facts. And we have to admit that we know less about UI than people who write HIG. This is why, while I really dislike things like Document settings in File menu, I am a bit embarrassed to criticize you choices. But I'll find a way around it ;) [*] JMarc [*] when I am not at ease with a choice that seems to be dictated by a HIG, I tend to (1) put the finger on what I do not like and (2) see if the intent of the HIG is really to enforce that.
Re: menu structure
Jean-Marc Lasgouttes wrote: This is why, while I really dislike things like Document settings in File menu, I am a bit embarrassed to criticize you choices. But I'll find a way around it ;) [*] If we assume (for a moment) that there is no Document-menu, where would you put the Document Settings? Edit? Format? Tools? /Konrad
Re: menu structure
Konrad Hofbauer wrote: Jean-Marc Lasgouttes wrote: This is why, while I really dislike things like Document settings in File menu, I am a bit embarrassed to criticize you choices. But I'll find a way around it ;) [*] If we assume (for a moment) that there is no Document-menu, where would you put the Document Settings? Edit? Format? Tools? Format. Probably at the top. rh
Re: menu structure
Konrad Hofbauer [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes wrote: This is why, while I really dislike things like Document settings in File menu, I am a bit embarrassed to criticize you choices. But I'll find a way around it ;) [*] If we assume (for a moment) that there is no Document-menu, where would you put the Document Settings? Edit? Format? Tools? Formats or Tools. JMarc
Re: menu structure
Konrad Hofbauer wrote: Pavel Sanda wrote: just to give some feedback the file/document distinction to me as a user is quite clear Can you please (honestly) explain this distinction to me (or define)? I feel like I am missing something here ... I didn't follow this exact discussion, but if you think of a book that consists of a master file and several childs, the document would be the whole (the document settings would apply to the whole book), whereas the files are the electronic entities. Jürgen
Re: menu structure
Jürgen Spitzmüller wrote: Can you please (honestly) explain this distinction to me (or define)? I feel like I am missing something here ... I didn't follow this exact discussion, but if you think of a book that consists of a master file and several childs, the document would be the whole (the document settings would apply to the whole book), whereas the files are the electronic entities. This is the only situation that came to my mind, too. Here this distinction makes sense, and, of course I agree. In terms of GUI I find the master/child case handled not so well by LyX. LyX wonderfully does its magic there behind the scenes, but we do not have much GUI to control this (and give feedback to the user). But it seems hard to me to make it better without adding complexity for single-file documents (which is likely the more frequent usage case). Example: The document settings do not apply to the whole book if I click onto Document Settings while I am in a child document - something that is not obvious. /Konrad
Re: menu structure
Konrad Hofbauer wrote: Example: The document settings do not apply to the whole book if I click onto Document Settings while I am in a child document - something that is not obvious. Right. However, there are cases where you want to have different settings in a child document (if you compile that separately). So we should probably have a Master document settings entry in such cases. Jürgen
Re: menu structure
Format. Probably at the top. +1
Re: menu structure
Konrad Hofbauer <[EMAIL PROTECTED]> writes: > And my impression from the earlier thread was that we should build > something based on HIGs, e.g., > > JMarc: "the menu structure should be done after > looking at as many HIG and good quality mainstream programs as > possible." > > JMarc again: "We cannot discuss on preferences, only on facts. And we > have to admit that we know less about UI than people who write HIG." This is why, while I really dislike things like Document settings in File menu, I am a bit embarrassed to criticize you choices. But I'll find a way around it ;) [*] JMarc [*] when I am not at ease with a choice that seems to be dictated by a HIG, I tend to (1) put the finger on what I do not like and (2) see if the intent of the HIG is really to enforce that.
Re: menu structure
Jean-Marc Lasgouttes wrote: This is why, while I really dislike things like Document settings in File menu, I am a bit embarrassed to criticize you choices. But I'll find a way around it ;) [*] If we assume (for a moment) that there is no Document-menu, where would you put the Document Settings? Edit? Format? Tools? /Konrad
Re: menu structure
Konrad Hofbauer wrote: Jean-Marc Lasgouttes wrote: This is why, while I really dislike things like Document settings in File menu, I am a bit embarrassed to criticize you choices. But I'll find a way around it ;) [*] If we assume (for a moment) that there is no Document-menu, where would you put the Document Settings? Edit? Format? Tools? Format. Probably at the top. rh
Re: menu structure
Konrad Hofbauer <[EMAIL PROTECTED]> writes: > Jean-Marc Lasgouttes wrote: >> This is why, while I really dislike things like Document settings in >> File menu, I am a bit embarrassed to criticize you choices. But I'll >> find a way around it ;) [*] > > If we assume (for a moment) that there is no Document-menu, where > would you put the Document Settings? > > Edit? Format? Tools? Formats or Tools. JMarc
Re: menu structure
Konrad Hofbauer wrote: > Pavel Sanda wrote: > > just to give some feedback the file/document distinction to me as a user > > is quite clear > > Can you please (honestly) explain this distinction to me (or define)? > I feel like I am missing something here ... I didn't follow this exact discussion, but if you think of a book that consists of a master file and several childs, the document would be the whole (the document settings would apply to the whole book), whereas the files are the electronic entities. Jürgen
Re: menu structure
Jürgen Spitzmüller wrote: Can you please (honestly) explain this distinction to me (or define)? I feel like I am missing something here ... I didn't follow this exact discussion, but if you think of a book that consists of a master file and several childs, the document would be the whole (the document settings would apply to the whole book), whereas the files are the electronic entities. This is the only situation that came to my mind, too. Here this distinction makes sense, and, of course I agree. In terms of GUI I find the master/child case handled not so well by LyX. LyX wonderfully does its magic there behind the scenes, but we do not have much GUI to control this (and give feedback to the user). But it seems hard to me to make it better without adding complexity for single-file documents (which is likely the more frequent usage case). Example: The document settings do not apply to the whole book if I click onto Document Settings while I am in a child document - something that is not obvious. /Konrad
Re: menu structure
Konrad Hofbauer wrote: > Example: The document settings do not apply to the whole book if I click > onto Document Settings while I am in a child document - something that > is not obvious. Right. However, there are cases where you want to have different settings in a child document (if you compile that separately). So we should probably have a "Master document settings" entry in such cases. Jürgen
Re: menu structure
> Format. Probably at the top. > +1
RE: menu structure
konrad wrote: Edwin (and others), great thanks for starting to work on this! thanks for having a look as well... I have a number of suggestions for changes, strictly based on the HIG [1] (except those sentences starting with IMO). just as a side note; i think it is good to have some directions, but i don't think we should treat the apple hig as the holy bible (personally i like apples, but as a fruit). as i see it many of these ui design decisions (also in the apple hig) are as much about convention as about logic. apple is one convention, windows another. lyx runs on many platforms so we should try something which people on all platforms recognize and don't get lost in... but let's see: Instead of having different ui/inc-files circulating around, I think it makes more sense if you maintain the master version and include from my suggestion what you deem appropriate. OK ??? sure, but we need to reach some consensus on the list (and solve the shortcuts issue) File *** New Window New Tab New File ... IMO: Yes, it looks a bit clustered with all the different New and Close, but this is what they do (and also removes current confusion). current as in lyx 1.5? or current as in the file i send? i think in the latter there is not much confusion concerning file and windowing/view stuff... Concerning Import/Export: unrelated to menus... *** Edit *** According to HIG, no separator above Select All. ok Move Paragraph Up/Down this is for the edit menu i think, it is about ordering/contents and not formatting and Text/Paragraph Styles would more be something for a (HIG-recommended) Format-Menu, but we don't have that since these four things would be the only entries (?). that's indeed a possibility *** Window vs. View *** According to HIG there should be: 1) a VIEW menu for all what concerns appearance WITHIN a window and [6] 2) a WINDOW menu for managing the multiple windows. [7] i think i prefer the current (ie last version i send). i realize that it put these things together, but it makes a stricter separation between the document and the view/window. the reason why i don't like this view menu, is that view is a verb and a noun and this leads to confusion (see below). imo of course. *** Window *** According to HG [5] putting Source and Navigation here is perfect! I would call them (to be consistent): View Source and View Navigation an illustration of why i don't like this view menu too much. it is confusing, is view on the document or stuff you want to view. if we would want to insist on similar naming i would also prefer navigation panel and source panel But all other items do NOT belong here according to HIG, but into a View menu. on apple... What also belongs here but we do not have: Minimize Maximize shrug *** View *** again, i don't really like this myself So this is a new menu following [6]. I suggest: Open All Insets Close All Insets note that this is document specific. so is are we in a document menu or a view menu. confusing if you ask me. another reason why i am not a fan of a view menu... *** Document *** There is nothing left for this menu, and the HIG give no indication whatsoever that we should have this. but document is less ambigous than view... *** Navigate *** Clearly an application-specific menu, everything fine here. Except: A second level of sub-menus is forbidden. (p.174) Suggestion: Just put all the lists on the first level (and group them with a spearator), with the items in the sub-menug. this will result in menu which is very long. try this with the user guide in fact, i would drop this navigate menu. the navigation panel is much more convenient. we could think of a adding a navigate toolbar with buttons for next section, note, table and the bookmarks... *** Table *** Left/Center/Right/Top/... miss a verb. But: see Format, I would move it there. a possibility indeed *** Format *** According to HIG this menu should be there [9]. I would suggest: Capitalize Uppercase Lowercase -- Customized Text Style ... Dissolve CharStyle (what is this ???) -- Paragraph Style ... got no idea what that means either;-) Move Paragraph Up Move Paragraph Down for the edit menu -- Table (all into sub what is in Table MainMenu now) yes *** Math *** Looks good. It could go into Format as well, but it is too large for a sub-menu (and would have sub-sub-menues then). According HIG it is OK to promote it to a full menu in such a situation. i agree *** Insert *** Looks good this is a bit of a mess i think (it is very full with little grouping), but i do not really see how we can improve it... , except: IMO Footnotes and marginal notes are Notes, and we have a submenu called Note, so they should be there. A note is a note is a note. even if there is the word note does not mean they have the same use. the notes in the submenu are
Re: menu structure
Hi Edwin, thanks for your comments. leuven edwin wrote: konrad wrote: just as a side note; i think it is good to have some directions, but i don't think we should treat the apple hig as the holy bible (personally i like apples, but as a fruit). as i see it many of these ui design decisions (also in the apple hig) are as much about convention as about logic. apple is one convention, windows another. lyx runs on many platforms so we should try something which people on all platforms recognize and don't get lost in... This is not just a side note, but I think the most important priciple question! 1) I think it was mostly agreed on the earlier discussion (by those who contributed), that we should stick to one HIG. So I would indeed say that the HIG (whichever we use) is the holy bible. This is the wrong place to put personal preferences, because people have different preferences. We should try to stick as much as possible to the HIG. If you do not agree to this, then for me the discussion ends here. (No rudeness meant here - I am willing to discuss how to interpret a HIG and which way conforms most to it, but unfortunately I do not have the time to discuss personal preferences, especially by email.) * 2) You cited in your proposal Apple's HIG, which I think is a well thought one (because Apple a) does in general not care too much about legacy and b) has pretty good usability). Would you have cited Vista's HIG, then I would have used that. but let's see: Instead of having different ui/inc-files circulating around, I think it makes more sense if you maintain the master version and include from my suggestion what you deem appropriate. OK ??? sure, but we need to reach some consensus on the list (and solve the shortcuts issue) File *** New Window New Tab New File ... IMO: Yes, it looks a bit clustered with all the different New and Close, but this is what they do (and also removes current confusion). current as in lyx 1.5? or current as in the file i send? i think in the latter there is not much confusion concerning file and windowing/view stuff... I meant current as in what I proposed. In the file you sent (maybe also in the standard-ui) Close does the wrong thing - it commonly closes the view, not the file. Concerning Import/Export: unrelated to menus... *** Edit *** According to HIG, no separator above Select All. ok Move Paragraph Up/Down this is for the edit menu i think, it is about ordering/contents and not formatting ok. and Text/Paragraph Styles would more be something for a (HIG-recommended) Format-Menu, but we don't have that since these four things would be the only entries (?). that's indeed a possibility *** Window vs. View *** According to HIG there should be: 1) a VIEW menu for all what concerns appearance WITHIN a window and [6] 2) a WINDOW menu for managing the multiple windows. [7] i think i prefer the current (ie last version i send). i realize that it put these things together, but it makes a stricter separation between the document and the view/window. the reason why i don't like this view menu, is that view is a verb and a noun and this leads to confusion (see below). imo of course. But there is a View menu everywhere - in the XP HIG, Vista HIG, Apple HIG, Wordpad, Office 2003, ... Don't refuse just because you don't like it. *** Window *** According to HG [5] putting Source and Navigation here is perfect! I would call them (to be consistent): View Source and View Navigation an illustration of why i don't like this view menu too much. it is confusing, is view on the document or stuff you want to view. see HIG. like it or not. if we would want to insist on similar naming i would also prefer navigation panel and source panel If it is under window, then it must have a verb. see HIG. But all other items do NOT belong here according to HIG, but into a View menu. on apple... and windows. What also belongs here but we do not have: Minimize Maximize shrug *** View *** again, i don't really like this myself which it isn't about. sorry, maybe introduce next time such a proposal as this is what I like (then there is no right or wrong), but if you introduce it as this is following apple's HIG ... (also maybe I misunderstood that). So this is a new menu following [6]. I suggest: Open All Insets Close All Insets note that this is document specific. I did not know that, I see know. It should not be like this (i.e. Inset states should be independent in multiple views IMO), but this is another topic... so is are we in a document menu or a view menu. confusing if you ask me. another reason why i am not a fan of a view menu... *** Document *** There is nothing left for this menu, and the HIG give no indication whatsoever that we should have this. but document is less ambigous than view... But view is standard in the three HIG I looked at, and
RE: menu structure
but let's see: attached the reworked menu, following most of your suggestions But there is a View menu everywhere - in the XP HIG, Vista HIG, Apple HIG, Wordpad, Office 2003, ... so now possibly also soon in lyx... Don't refuse just because you don't like it. that's what all religious nutcakes say, but... ...as a proof of my openmindedness, see attached Open All Insets Close All Insets note that this is document specific. I did not know that, I see know. It should not be like this (i.e. Inset states should be independent in multiple views IMO), but this is another topic... collapsed status is also saved in the document (like it or not), so i have put this in the file menu for now *** Navigate *** Except: A second level of sub-menus is forbidden. (p.174) Suggestion: Just put all the lists on the first level (and group them with a spearator), with the items in the sub-menu. this will result in menu which is very long. try this with the user guide I see. Try it with Intro.lyx, and it looks odd. not sure what you mean. another thing is that this is hardcoded so it's probably not going to change soon. then again, we could still consider the following: in fact, i would drop this navigate menu. the navigation panel is much more convenient. we could think of a adding a navigate toolbar with buttons for next section, note, table and the bookmarks... But then let us call the Note-submenu something different (Comment ?). Because the Greyed Out does show in the output. Also, we should unify the naming of this three Comment items. i never use this, perhaps others have suggestions? Please decide on how you want to proceed: a) based on what you think makes most sense (i.e. what you like) OR b) based on a holy-bible-HIG. that still open for discussion i suppose, and not only up to us. but thanks for your input. so the attached has a view menu for the sake of hig-ness, but note it is *very* empty. it has only 2 items: toolbars and fullscreen. as far as i am concerned we would put these in the application menu and be done with it. for the rest it is a BIG improvement on the current menu i think. i urge everybody to give the attached a try ed. hig.ui Description: hig.ui hig.inc Description: hig.inc
RE: menu structure
[4] Our document settings are file-specific parameters, saved with the
document, so it is IMO very similar to the Page Setup-item in the HIG:
Page Setup... . Opens a dialog for specifying printing parameters such
as paper size and printing orientation. These parameters are saved
with
the document.
Good to see that two people have stand up already...
IMHO
{
Maybe, it is a HIG interpretation thing, but I'm seriously doubting that
the HIG says that content-related stuff like the Document settings...
must be in the File menu. Things like page setup do not influence the
content of the document in any way, besides how it is printed.
This also holds for the Statistics item, it is really not just a file
statistic. It is something that is used while generating content,
something that influences whether I can add another sentence to the
abstract or not. It also counts words in a selection. So, it is not
really a file statistic.
In conclusion, the interpretation of the argument that it is
file-specific and that it is saved with the document might be
reconsidered, because I feel that this only holds for file-specific
options that do not influence the content in any way.
Last, I agree that it is a good approach to look at independent,
well-thought HIGs, but don't forget the other constrictions that were
raised in the discussion last days. For example, LyX users are used to
having a Document-Settings... Item. They will be disturbed if they have
to look for one of the most important menu items.
I dreamt last night of a Document menu with the grouped tools (They
really must be next to each other, otherwise I will be looking for them
over and over again).
DOCUMENT MENU:
- Spellchecker, that checks my document for spelling errors,
- Thesaurus, just because it is next to the Spellchecker,
- Statistics, counting words in my document or in specific parts of my
document,
=
- Branching, all options in the document-settings dialog are stored in
the document except branching information, that is filtered out by LyX
itself, so it deserves an item on its own.
=
- Settings..., one of the most important menu items IMO, which users
will find when it's in the Document menu, .. Oh and it does of course
say something about the document.
}
Please consider this,
Vincent
RE: menu structure
as in attached menu order: file, edit, format, insert, math, go to, typeset, window, document, application, help toolbars is in application fullscreen in window i like this myself (if I can say that..) hig2.inc Description: hig2.inc hig2.ui Description: hig2.ui
Re: menu structure
Edwin, for the sake of hig-ness - I guess that means I am higgy? Quite possible. :-) About the open/close windows, tabs, etc., and independent of the menue discussion, I don't quite get what does what (esp. the Close tab group). Should that not be a simple Close tab-functionality? leuven edwin wrote: but let's see: attached the reworked menu, following most of your suggestions Looks very higgy. :) But there is a View menu everywhere - in the XP HIG, Vista HIG, Apple HIG, Wordpad, Office 2003, ... so now possibly also soon in lyx... Don't refuse just because you don't like it. that's what all religious nutcakes say, but... ...as a proof of my openmindedness, see attached Open All Insets Close All Insets note that this is document specific. I did not know that, I see know. It should not be like this (i.e. Inset states should be independent in multiple views IMO), but this is another topic... collapsed status is also saved in the document (like it or not), so i have put this in the file menu for now. Conceptually one can argue for one or the other. But just because something is stored in the document, does not mean it needs to be in the File-menu. IMO (!!! - don't care about it!) I would still see it as a classical element of the View-Menu. That it also affects the appearance in other windows (not just the current), well ... too bad. *** Navigate *** Except: A second level of sub-menus is forbidden. (p.174) Suggestion: Just put all the lists on the first level (and group them with a spearator), with the items in the sub-menu. this will result in menu which is very long. try this with the user guide I see. Try it with Intro.lyx, and it looks odd. not sure what you mean. another thing is that this is hardcoded so it's probably not going to change soon. Right. It is OK as it is right now, I would say. then again, we could still consider the following: in fact, i would drop this navigate menu. the navigation panel is much more convenient. Personally, I never use the Navigate-Menu in 1.5 at all, so I would not miss it. But don't know what other people do ... we could think of a adding a navigate toolbar with buttons for next section, note, table and the bookmarks... Sounds good to me! But then let us call the Note-submenu something different (Comment ?). Because the Greyed Out does show in the output. Also, we should unify the naming of this three Comment items. i never use this, perhaps others have suggestions? How about Comment LyX Comment LaTeX Comment Printed Comment (or Typeset Comment) Please decide on how you want to proceed: a) based on what you think makes most sense (i.e. what you like) OR b) based on a holy-bible-HIG. that still open for discussion i suppose, and not only up to us. but thanks for your input. so the attached has a view menu for the sake of hig-ness, but note it is *very* empty. it has only 2 items: toolbars and fullscreen. as far as i am concerned we would put these in the application menu and be done with it. According to HIG, Split Left/Right and Split Top/Bottom clearly belong into View, not Window, I would suppose. (And with the Open/Close Insets discussed above, the Menu size would be just right.) About the Application-menu: I am not sure if what I see here (on the Mac) is what you meant me to see, and how it looks on windows/linux. Historically (and currently, and hopefully also in the future), the Mac has a few commands in a LyX-menu (augmented by other commands from the OS), that affect the application. That should be: 1) About LyX 2) Preferences 3) Reconfigure 4) TeX Information (that could be in Windows though) 5) Quit I do NOT think we should have a similar Application menu on windows/linux, but but 1) in Help, and 5) at the bottom of the File menu (I think every windows and gnome app has that). 2) 3) 4) are problematic. Gnome has the Preferences always in the Edit-Menu. I would probably put 2) 3) 4) into the File menu at the bottom, but I can see why one would object. An Application menu, is that frequently done in other apps? for the rest it is a BIG improvement on the current menu i think. Very much agreed! I hope some others will look at it, too! /Konrad
RE: menu structure
as in attached Sort of.. ;-) i like this myself (if I can say that..) I like it too, but... (just being constructive) - it is very sneaky to remove the View menu again.. Moving all items from the Window menu into the View menu would ALSO be an option... - The File-New Window and File-Close Window don't deserve to be the first items. All applications I know have a first item called New (File) and the first item after the first separator Close (File) *. The new/close window options are hardly used (just a guess) and are now really in the way when I want a new or to close a file (because of habit/intuition). * This of course only holds when applications can create new files or open them. I know that IE has a first item New-Window, but that is a totally different application. - Following 'my' logic about the File menu and content-related stuff, the Compressed item should be in the File menu. It has nothing to do with the content, just with how it is saved. Would it be an option to insert between Save all.. and Revert to saved (or maybe one below) an item Save compressed.. ? - What is the difference between the Latex Source Panel, Navigation panel and Toolbars ? Shouldn't these be next to each other ? Preferably in a View menu, otherwise in a Window menu. ? Vincent
Re: menu structure
Vincent van Ravesteijn - TNW wrote: Maybe, it is a HIG interpretation thing, but I'm seriously doubting that the HIG says that content-related stuff like the Document settings... must be in the File menu. Correct. (but I still think it is the right place) Things like page setup do not influence the content of the document in any way, besides how it is printed. This also holds for the Statistics item, it is really not just a file statistic. It is something that is used while generating content, something that influences whether I can add another sentence to the abstract or not. It also counts words in a selection. So, it is not really a file statistic. Indeed. (But you could say the same for Document. IMO File and Document is the same thing.) In conclusion, the interpretation of the argument that it is file-specific and that it is saved with the document might be reconsidered, because I feel that this only holds for file-specific options that do not influence the content in any way. Very open to this. Last, I agree that it is a good approach to look at independent, well-thought HIGs, ... Can this be our main-line-of-argumentation? I think it is the only way how to come up with something consistens. For example, LyX users are used to having a Document-Settings... Item. They will be disturbed if they have to look for one of the most important menu items. IMO - no, no, no. If we start to care about legacy, nothing good will come out. I dreamt last night of a Document menu with the grouped tools (They really must be next to each other, otherwise I will be looking for them over and over again). DOCUMENT MENU: - Spellchecker, that checks my document for spelling errors, - Thesaurus, just because it is next to the Spellchecker, - Statistics, counting words in my document or in specific parts of my document, = - Branching, all options in the document-settings dialog are stored in the document except branching information, that is filtered out by LyX itself, so it deserves an item on its own. = - Settings..., one of the most important menu items IMO, which users will find when it's in the Document menu, .. Oh and it does of course say something about the document. } 1) Can you please define what the Document menu is good for (in a future-compatible abstract way)? Any HIG? 2) You are on Windows? The list of things you gave for your Document menu is mostly what Word and friends have as Tools menu? In fact, such a Tools menu is part of the XP/Vista HIG. So if we have such a group of things, let us at least call it Tools. We start to mix HIG's though. /Konrad
Re: menu structure
Vincent van Ravesteijn - TNW wrote: - it is very sneaky to remove the View menu again.. Moving all items from the Window menu into the View menu would ALSO be an option... If you propose something like this, then please propose a LyX-Menu-HIG. - The File-New Window and File-Close Window don't deserve to be the first items. All applications I know have a first item called New (File) and the first item after the first separator Close (File) *. The new/close window options are hardly used (just a guess) and are now really in the way when I want a new or to close a file (because of habit/intuition). I like it though the way it is - because it is logic (all opens and closes in one group). * This of course only holds when applications can create new files or open them. I know that IE has a first item New-Window, but that is a totally different application. Same for (cross-platform) firefox and safari. But of course, your argument holds. - Following 'my' logic about the File menu and content-related stuff, the Compressed item should be in the File menu. It has nothing to do with the content, just with how it is saved. Would it be an option to insert between Save all.. and Revert to saved (or maybe one below) an item Save compressed.. ? I agree! - What is the difference between the Latex Source Panel, Navigation panel and Toolbars ? Shouldn't these be next to each other ? Preferably in a View menu, otherwise in a Window menu. ? That Panels are seen (following the HIG) as separate windows, whereas Toobar is a within-the-window option. /Konrad
Re: menu structure
Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: Maybe, it is a HIG interpretation thing, but I'm seriously doubting that the HIG says that content-related stuff like the Document settings... must be in the File menu. Things like page setup do not influence the content of the document in any way, besides how it is printed. I do not think either that it is a good idea. The idea as I see it is to put the things that directly affect margins or paper size (because it is near to FilePrint), but certainly not all document settings. In conclusion, the interpretation of the argument that it is file-specific and that it is saved with the document might be reconsidered, because I feel that this only holds for file-specific options that do not influence the content in any way. I think it is related to actions of saving the file to disk or to printer. In this sense, modifying paper size might be good (like changing format in Save As) but the rest is not. JMarc
Re: menu structure
Konrad Hofbauer [EMAIL PROTECTED] writes: For example, LyX users are used to having a Document-Settings... Item. They will be disturbed if they have to look for one of the most important menu items. IMO - no, no, no. If we start to care about legacy, nothing good will come out. Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. JMarc
Re: menu structure
leuven edwin [EMAIL PROTECTED] writes: I did not know that, I see know. It should not be like this (i.e. Inset states should be independent in multiple views IMO), but this is another topic... collapsed status is also saved in the document (like it or not), so i have put this in the file menu for now I would not do that. File menu is more for physical state of the document (so I guess Compressed can belong there). If you do that, why not put Insert Table Float too??? JMarc
Re: menu structure
leuven edwin wrote: i like this myself (if I can say that..) I don't. Which HIG does it follow? /Konrad
RE: menu structure
collapsed status is also saved in the document (like it or not), so i have put this in the file menu for now I would not do that. File menu is more for physical state of the document (so I guess Compressed can belong there). If you do that, why not put Insert Table Float too??? hey don't shoot the messanger! just following the hig...
Re: menu structure
leuven edwin [EMAIL PROTECTED] writes: collapsed status is also saved in the document (like it or not), so i have put this in the file menu for now I would not do that. File menu is more for physical state of the document (so I guess Compressed can belong there). If you do that, why not put Insert Table Float too??? hey don't shoot the messanger! just following the hig... I only followed the discussion with an eye. Could some nice soul point me to the relevant HIG part? JMarc
RE: Re: menu structure
Maybe, it is a HIG interpretation thing, but I'm seriously doubting that the HIG says that content-related stuff like the Document settings... must be in the File menu. Correct. (but I still think it is the right place) Things like page setup do not influence the content of the document in any way, besides how it is printed. This also holds for the Statistics item, it is really not just a file statistic. It is something that is used while generating content, something that influences whether I can add another sentence to the abstract or not. It also counts words in a selection. So, it is not really a file statistic. Indeed. (But you could say the same for Document. IMO File and Document is the same thing.) Well, I just wanted to make a distinction between content-related and content-unrelated items. (And I chose Document, because LyX has already a Document menu and I do care about legacy, see below) Last, I agree that it is a good approach to look at independent, well-thought HIGs, ... Can this be our main-line-of-argumentation? I think it is the only way how to come up with something consistens. For example, LyX users are used to having a Document-Settings... Item. They will be disturbed if they have to look for one of the most important menu items. IMO - no, no, no. If we start to care about legacy, nothing good will come out. Again, I do care about legacy; LyX deserves its own identity (in case of doubt). 1) Can you please define what the Document menu is good for (in a future-compatible abstract way)? Any HIG? Can't, guilty as charged. 2) You are on Windows? The list of things you gave for your Document menu is mostly what Word and friends have as Tools menu? In fact, such a Tools menu is part of the XP/Vista HIG. So if we have such a group of things, let us at least call it Tools. We start to mix HIG's though. Indeed, adjusting interpretation, deviating slightly as not everything might be captured in the HIG, and the legacy thing of course. As for the File menu, I can reason the same for the Edit menu... (and you might look in the HIG whether this is true/false or open for interpretation). Besides the Change tracking and Spellchecker items, all items in the Edit menu are only pure 'management'-like items. These items have nothing to do with what is being edited, only moving around chunks of text/images/newlines/insets/etc. In contrary, the Spellchecker look at what is being processed, whether it is spelled correctly. The Thesaurus look at how the user could say it differently, maybe better, maybe enrichening the language use of the writer. Last, change tracking displays (maybe) another opinion of another author, it represents enhancements. IMO it is much more than administration (but this might be discussable). - Statistics / Document Settings may be moved somewhere else, because they are content-related, - Spellchecker / Thesaurus may be moved, because they relate to the content of the text that is being processed. And because the common divisor of these problem cases is that they are content-related, I put them together in a content-related-menu aka Document menu (from the viewpoint of legacy I think this is a good name, but this might be discussable.) That's my reason for the Document menu. What if the HIG doesn't have the correct place for these items...? /Konrad Vincent
RE: menu structure
- it is very sneaky to remove the View menu again.. Moving all items from the Window menu into the View menu would ALSO be an option... not sneaky, i just moved the 2 items in the view menu. the window menu was much fuller so i makes sense not to name it view. of course we could s/window/view/ - The File-New Window and File-Close Window don't deserve to be the first items. hig guidelines according to konrad The new/close window options are hardly used (just a guess) and are now really in the way when I want a new or to close a file (because of habit/intuition). again, hig guidelines. i can see a rationale for moving them down... - Following 'my' logic about the File menu and content-related stuff, the Compressed item should be in the File menu. sure Would it be an option to insert between Save all.. and Revert to saved (or maybe one below) an item Save compressed.. ? not atm since it is a toggling menu item - What is the difference between the Latex Source Panel, Navigation panel and Toolbars ? Shouldn't these be next to each other ? Preferably in a View menu, otherwise in a Window menu. ? in the window menu according to the hig... ed.
Re: menu structure
Jean-Marc Lasgouttes wrote: Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has Properties in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. What is the difference between file and document in the first place ??? I am not quite convinced about Document==Content. And even if we do so, it is not clear/logical to the user. /Konrad
Re: menu structure
Konrad Hofbauer wrote: Jean-Marc Lasgouttes wrote: Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has Properties in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. Forgot (sorry for the noise): And both don't have any more document-level settings, as far as I can see. /Konrad
Re: menu structure
Konrad Hofbauer [EMAIL PROTECTED] writes: Word 2003 has the Page Setup in File, OO has Properties in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. What is the difference between file and document in the first place ??? In OO FileProperties is not very conclusive... I do not have word 2003 here, but what I remember is that only page layout can be changed in File menu. In our document settings, we other style-related entries that fit in Format menu in word. I am not quite convinced about Document==Content. And even if we do so, it is not clear/logical to the user. I understand you concern. But I strongly dislike putting all in File. JMarc
Re: menu structure
[EMAIL PROTECTED] wrote: leuven edwin [EMAIL PROTECTED] writes: collapsed status is also saved in the document (like it or not), so i have put this in the file menu for now I would not do that. File menu is more for physical state of the document (so I guess Compressed can belong there). If you do that, why not put Insert Table Float too??? hey don't shoot the messanger! just following the hig... I only followed the discussion with an eye. Could some nice soul point me to the relevant HIG part? That is my job ;-) but I disagree here. In my interpretation of the HIG it belongs into View: The View menu provides commands that affect how users see a window’s content; it does not provide commands to select specific document windows to view or to manage a specific document window. Commands to organize, select, and manage windows are in the Window menu. And about the discussion if we should merge View and Window - menu: Every application I seen on my desktop, all Apple apps, all Mozilla apps, OpenOffice, Word 2003 (on XP), ... have a View AND a WINDOW menu, and there is a rationale behind it. Neither Word, OO or any of my Text-Editors has a Document-menu. /Konrad
Re: menu structure
Konrad Hofbauer [EMAIL PROTECTED] writes: I only followed the discussion with an eye. Could some nice soul point me to the relevant HIG part? That is my job ;-) It would be nice to start a wiki page with links to the apple (or vista or...) HIGs for the different parts of the menus. but I disagree here. In my interpretation of the HIG it belongs into View: The View menu provides commands that affect how users see a window’s content; it does not provide commands to select specific document windows to view or to manage a specific document window. Commands to organize, select, and manage windows are in the Window menu. Personally, I would put it in edit. And about the discussion if we should merge View and Window - menu: Every application I seen on my desktop, all Apple apps, all Mozilla apps, OpenOffice, Word 2003 (on XP), ... have a View AND a WINDOW menu, and there is a rationale behind it. Neither Word, OO or any of my Text-Editors has a Document-menu. I would be nice to dig the old thread concerning the current menu structure. John Levon had a pretty through analysis of Higs at the time. JMarc
Re: menu structure
Jean-Marc Lasgouttes wrote: Konrad Hofbauer [EMAIL PROTECTED] writes: Word 2003 has the Page Setup in File, OO has Properties in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. What is the difference between file and document in the first place ??? In OO FileProperties is not very conclusive... I do not have word 2003 here, but what I remember is that only page layout can be changed in File menu. In our document settings, we other style-related entries that fit in Format menu in word. You remember correctly. I am not quite convinced about Document==Content. And even if we do so, it is not clear/logical to the user. I understand you concern. But I strongly dislike putting all in File. And I disklike a document-menu: It breaks the cross-platform HIG concept of File - View - Window menus, and I do not understand what is the difference between a file and a document. /Konrad
Re: menu structure
Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: What if the HIG doesn't have the correct place for these items...? You remove the feature. JMarc
Re: menu structure
Konrad Hofbauer [EMAIL PROTECTED] writes: Forgot (sorry for the noise): And both don't have any more document-level settings, as far as I can see. Not a FormatPage, by chance? A toolsLanguage? JMarc
Re: menu structure
On Wed, Sep 17, 2008 at 06:49:05PM +0200, Jean-Marc Lasgouttes wrote: And about the discussion if we should merge View and Window - menu: Every application I seen on my desktop, all Apple apps, all Mozilla apps, OpenOffice, Word 2003 (on XP), ... have a View AND a WINDOW menu, and there is a rationale behind it. Neither Word, OO or any of my Text-Editors has a Document-menu. I would be nice to dig the old thread concerning the current menu structure. John Levon had a pretty through analysis of Higs at the time. I've been idly watching this thread. It's obviously unfair of me to complain about anything since it's been so long since I did something useful, but I do think if Edwin wants to re-work everything, it'd be good if he did the same kind of analysis I did first time around: - what the biggest problems are with the current structure - why a new structure would help - the guiding principles behind the design of the new structure - what each of the main HIGs have to say about both the old and new setup I'm not necessarily saying that a re-org shouldn't happen, but I do think people should bear in mind that all menu structures have problems, and all re-workings cause a lot of upheaval. That is, you'd better be pretty sure that the new system is so much better that it's worth pissing off your users. I thought so, and gained enough consensus to commit the changes, but I know there's still LyX hackers around who disagreed with me on this the *first* time round. I did this back in the day, so I'm aware of the kind of scars you can accumulate by upsetting folks in this way :) cheers, john
Re: menu structure
Vincent van Ravesteijn - TNW wrote: Well, I just wanted to make a distinction between content-related and content-unrelated items. (And I chose Document, because LyX has already a Document menu and I do care about legacy, see below) The name Document does not really transport the notion of content-related for me. Plus, it is very non-standard. Last, I agree that it is a good approach to look at independent, well-thought HIGs, ... Can this be our main-line-of-argumentation? I think it is the only way how to come up with something consistens. For example, LyX users are used to having a Document-Settings... Item. They will be disturbed if they have to look for one of the most important menu items. IMO - no, no, no. If we start to care about legacy, nothing good will come out. Again, I do care about legacy; LyX deserves its own identity (in case of doubt). Very much disagreed that LyX should have its own identity. Uniformity accross apps is IMHO very improtant and what makes an app simple to use. And this is why there are HIGs. 1) Can you please define what the Document menu is good for (in a future-compatible abstract way)? Any HIG? Can't, guilty as charged. 2) You are on Windows? The list of things you gave for your Document menu is mostly what Word and friends have as Tools menu? In fact, such a Tools menu is part of the XP/Vista HIG. So if we have such a group of things, let us at least call it Tools. We start to mix HIG's though. Indeed, adjusting interpretation, deviating slightly as not everything might be captured in the HIG, and the legacy thing of course. I am not sure I understand to what you want to say. As for the File menu, I can reason the same for the Edit menu... (and you might look in the HIG whether this is true/false or open for interpretation). Besides the Change tracking and Spellchecker items, all items in the Edit menu are only pure 'management'-like items. These items have nothing to do with what is being edited, only moving around chunks of text/images/newlines/insets/etc. In contrary, the Spellchecker look at what is being processed, whether it is spelled correctly. The Spellchecker is generally (across platforms) in an Edit or in a Tools menu. It has IMO nothing to do with Content. It is a Tool to check the spelling, or something that Edits text for me. The Thesaurus look at how the user could say it differently, maybe better, maybe enrichening the language use of the writer. So it's a perfect tool. ;-) Last, change tracking displays (maybe) another opinion of another author, it represents enhancements. IMO it is much more than administration (but this might be discussable). - Statistics / Document Settings may be moved somewhere else, because they are content-related, - Spellchecker / Thesaurus may be moved, because they relate to the content of the text that is being processed. And because the common divisor of these problem cases is that they are content-related, I put them together in a content-related-menu aka Document menu (from the viewpoint of legacy I think this is a good name, but this might be discussable.) That's my reason for the Document menu. You are developing your own rules and logic here (which might be perfectly reasonable !!!), but I think this is not what we should do - because we can come up with a hundred different logics, each being reasonable. What if the HIG doesn't have the correct place for these items...? For most of them the HIG does have the correct place, and we should only discuss about the remaining ones. /Konrad
RE: Re: menu structure
And I disklike a document-menu: It breaks the cross-platform HIG concept of File - View - Window menus, and I do not understand what is the difference between a file and a document. You may dislike it. I never said it has to be a Document menu; never said that it is very common to have a document menu. I only reasoned that some of the items did not belong to the place they were put according to the HIG. And to propose something else, I found a common factor and I remembered having a menu in LyX where they might fit in. Please, be welcome to reason where they should be. And both don't have any more document-level settings, as far as I can see. Format-Bullets Numbering Format-Columns Format-Styles and Formatting Format-Theme Table-AutoFormat... MathType-Set Eq. Prefs. Tools-Templates Now it's time for promotion: How does Word do it: you have to specify for each table how it looks like. You have to select all text to change the document-default font. Luckily LyX has a lot of document-level settings, such that I'd have to specify once how something should look like. Praise LyX by having its Document menu, because that's where it's good at (and it changes at little as possible). /Konrad Vincent
Re: menu structure
Jean-Marc Lasgouttes wrote: Konrad Hofbauer [EMAIL PROTECTED] writes: Forgot (sorry for the noise): And both don't have any more document-level settings, as far as I can see. Not a FormatPage, by chance? A toolsLanguage? In that sense, yes, you are right. The question is what we learn by this - because our document settings are everything in one. /Konrad
Re: menu structure
Vincent van Ravesteijn - TNW wrote: I only reasoned that some of the items did not belong to the place they were put according to the HIG. And to propose something else, I found a common factor and I remembered having a menu in LyX where they might fit in. Sure. Please, be welcome to reason where they should be. Sorry (really), can you please tell me (again) which items you don't see fit? And both don't have any more document-level settings, as far as I can see. Format-Bullets Numbering Format-Columns Format-Styles and Formatting Format-Theme Table-AutoFormat... MathType-Set Eq. Prefs. Tools-Templates That would almost suggest to put our Document Settings into Format. ;-) Now it's time for promotion: How does Word do it: you have to specify for each table how it looks like. You have to select all text to change the document-default font. Luckily LyX has a lot of document-level settings, such that I'd have to specify once how something should look like. Praise LyX by having its Document menu, because that's where it's good at (and it changes at little as possible). You put me in the corner here. Of course I want to praise LyX!!! :-) I cannot do that enough! /Konrad
RE: Re: menu structure
Sorry (really), can you please tell me (again) which items you don't see fit? These could be in Document/Tools: [Edit] Spellcheck [Edit] Thesaurus [Edit] Change tracking [File] Statistics This one Document/Format: [File] Document Settings Somewhere else in the File menu: [File] New Window [File] Close Window You're right that maybe Document isn't the best name, but I'll really miss the Document menu and I am afraid users will get mad (Like John pointed at) and I really feel that having document-level settings makes working with LyX pleasant. You put me in the corner here. Of course I want to praise LyX!!! :-) I cannot do that enough! Sorry (really). Don't take me wrong.. You did well. /Konrad PS. Last mail for a while. Vincent
Re: menu structure
Konrad Hofbauer wrote: For example, LyX users are used to having a Document-Settings... Item. They will be disturbed if they have to look for one of the most important menu items. IMO - no, no, no. If we start to care about legacy, nothing good will come out. And it is worth remembering that we can still ship that classic default UI, or some version of it, for those who just want to stick with the original menus. rh
Re: menu structure
Vincent van Ravesteijn - TNW wrote: Somewhere else in the File menu: [File] New Window [File] Close Window The HIG do not really specify this (I only took that from Firefox and Safari). One could also argue that these two should be in Window. These could be in Document/Tools: [Edit] Spellcheck [Edit] Thesaurus [Edit] Change tracking [File] Statistics So maybe get a Tools-Menu after all? Edit- Spellcheck was by (Apple-)convention. This one Document/Format: [File] Document Settings This I see as the only real 'problem' child. But a document-menu just for the sake of having a 'Document Settings' I have doubts. You're right that maybe Document isn't the best name, but I'll really miss the Document menu and I am afraid users will get mad (Like John pointed at). But we should also think about new users. I just looked at 1.5 again. As well there, the Documents-menu should really be called Tools. This is IMO where much of the confusion comes from. I really feel that having document-level settings makes working with LyX pleasant. Of course! You put me in the corner here. Of course I want to praise LyX!!! :-) I cannot do that enough! Sorry (really). Don't take me wrong.. No worry, there was a :). You did well. This is nothing, zero, to what you all do every day on the design/implementation/debugging front PS. Last mail for a while. Same here. /Konrad
Re: menu structure
Konrad Hofbauer wrote: Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has Properties in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. What is the difference between file and document in the first place ??? I am not quite convinced about Document==Content. And even if we do so, it is not clear/logical to the user. just to give some feedback the file/document distinction to me as a user is quite clear and adding the items into file menu looks pretty messy. i hope it won't heat the discussion too much, but the holy-hig-bible position seems to me as a fraud, because once you start interpret any text, you will get whatsoever you want. the only change is that before you could honestly say i don't like document menu now you cover it behind some sophisticated arguments. that of course doesn't mean we shouldn't emphasize hig, but its another position than holy book. pavel
Re: menu structure
Pavel Sanda wrote: just to give some feedback the file/document distinction to me as a user is quite clear Can you please (honestly) explain this distinction to me (or define)? I feel like I am missing something here ... and adding the items into file menu looks pretty messy. That is another story. i hope it won't heat the discussion too much, but the holy-hig-bible position seems to me as a fraud, because once you start interpret any text, you will get whatsoever you want. But this is not what is happening! Nobody else has ever written something along the lines of ... but I would interpret the HIG such that Unfortunately. If you should not have noticed yet, I am the only one seriously talking about any HIG. the only change is that before you could honestly say i don't like document menu now you cover it behind some sophisticated arguments. I really try to avoid any like/dislike - it is always subjective. My initial long reply to Edwin's email was the result of having his proposal running, and going line-by-line through the HIG and trying to follow the HIG as close as possible. That there was nothing left for the Document-menu was a pure result of that process. Believe it or not, I have not thought about the Document menu even a single second, beforehand. I do not think I am hiding behind false arguments here. that of course doesn't mean we shouldn't emphasize hig, but its another position than holy book. Not sure I understand what you want to say with this. Wondering about your offend, /Konrad P.S. On accusing me of fraud / cover up: Have you really worked through http://permalink.gmane.org/gmane.editors.lyx.devel/110921 to be able to say so ??? I think it should be enough to support my claims once with a proper reference, and not repeating the same citations over and over again within the same thread.
Re: menu structure
Le 17 sept. 08 à 20:27, Konrad Hofbauer a écrit : P.S. On accusing me of fraud / cover up: Have you really worked through http://permalink.gmane.org/gmane.editors.lyx.devel/110921 to be able to say so ??? I think it should be enough to support my claims once with a proper reference, and not repeating the same citations over and over again within the same thread. Pavel, Konrad: I propose that you stop there, before things go too far :) I tried it at times, but it did not make any cause advance much. Cheers, JMarc
Re: menu structure
Jean-Marc Lasgouttes wrote: Le 17 sept. 08 à 20:27, Konrad Hofbauer a écrit : P.S. On accusing me of fraud / cover up: Have you really worked through http://permalink.gmane.org/gmane.editors.lyx.devel/110921 to be able to say so ??? I think it should be enough to support my claims once with a proper reference, and not repeating the same citations over and over again within the same thread. Pavel, Konrad: I propose that you stop there, before things go too far :) I tried it at times, but it did not make any cause advance much. And of course Pavel accused the Hig itself of fraud, not Konrad ;-) Quite franqly, I agree with Pavel here. I almost never use the menubar myself, especially now that we have context menus. The reason is that the things are often hard to find in the menubar. And I honestly don't see OO or Ms Office as good reference. As a user I want something that is useful to find features and Edwin first proposal was closer to my needs than current menubar. Yes, that is subjective but menubar discussion is all about subjectiveness isn't it? :-) Abdel.
Re: menu structure
Konrad Hofbauer wrote: Pavel Sanda wrote: just to give some feedback the file/document distinction to me as a user is quite clear Can you please (honestly) explain this distinction to me (or define)? I feel like I am missing something here ... i will try. when i go to the file, i'm usually looking for something which has something a) to do with files generally (ie it does not have anything to do with this in file particular. for example open another file.) b) or has something to do with this file - but it concerns its handling not its content - thats why i feel e.g. reversion or version control is ok in file menu, while properties would be lost in this menu. i hope it won't heat the discussion too much, but the holy-hig-bible position seems to me as a fraud, because once you start interpret any text, you will get whatsoever you want. But this is not what is happening! Nobody else has ever written something along the lines of ... but I would interpret the HIG such that Unfortunately. my thought was fortunately :) the only change is that before you could honestly say i don't like document menu now you cover it behind some sophisticated arguments. I really try to avoid any like/dislike - it is always subjective. i tried to say that our subjectivity is ok. if 90% of us say we dont like something which hig propose, then its bad luck for hig, not for us. My initial long reply to Edwin's email was the result of having his proposal running, and going line-by-line through the HIG and trying to follow the HIG as close as possible. if the new file menu is the result of hig, then i probably start abuse hig itself :D That there was nothing left for the Document-menu was a pure result of that process. Believe it or not, I have not thought about the Document menu even a single second, beforehand. I do not think I am hiding behind false arguments here. i got that feeling because firstly you said we should stick to hig and puting our personal preferences aside and few mails after just read the some sentence like i don't like the document menu... now rereading it again it seems to be a bit different issue, you dislike document because it violates hig :) my mistake. Wondering about your offend, /Konrad P.S. On accusing me of fraud / cover up: sorry for such a strong words :( , it was not my intention to accuse anybody of anything and turn the thread into personal exchange; i wanted to accuse the objective disputation based on holy-hig methodology as such, since i don't believe that things with likes / dislikes (e.g. menu) can be discussed this way. maybe just projecting my own psychology here... Have you really worked through http://permalink.gmane.org/gmane.editors.lyx.devel/110921 to be able to say so ??? no i havent worked as hard as you on this matter - only quickly read all the messages. its quite possible i just messed things up. i will try to keep my mouth more gentle next time :) pavel
Re: menu structure
Jean-Marc Lasgouttes wrote: Le 17 sept. 08 ? 20:27, Konrad Hofbauer a écrit : P.S. On accusing me of fraud / cover up: Have you really worked through http://permalink.gmane.org/gmane.editors.lyx.devel/110921 to be able to say so ??? I think it should be enough to support my claims once with a proper reference, and not repeating the same citations over and over again within the same thread. Pavel, Konrad: I propose that you stop there, before things go too far :) I tried it at times, but it did not make any cause advance much. uups i read it just after sending the mail, but i hope i was diplomatic enough :D pavel
Re: menu structure
Pavel Sanda wrote: i will try. when i go to the file, i'm usually looking for something which has something a) to do with files generally (ie it does not have anything to do with this in file particular. for example open another file.) b) or has something to do with this file - but it concerns its handling not its content - thats why i feel e.g. reversion or version control is ok in file menu, while properties would be lost in this menu. Ok -i will try to get that into my head. And, in contrast to this, the document-menu? i tried to say that our subjectivity is ok. if 90% of us say we dont like something which hig propose, then its bad luck for hig, not for us. But with the five people involved so far, you will never get the 90%. ;-) But seriously: I think that either we build something based on likes/dislikes, or something based on HIGs. In the later case, I am happy to be involved, in the earlier case I will not be involved very much (but just as happy). And my impression from the earlier thread was that we should build something based on HIGs, e.g., JMarc: the menu structure should be done after looking at as many HIG and good quality mainstream programs as possible. Jürgen: I'm opposed as well to I like it like that changes without reference to Interface Guidelines. JMarc again: We cannot discuss on preferences, only on facts. And we have to admit that we know less about UI than people who write HIG. Richard: So what we need is a complete alternative proposal, backed up with something akin to knowledge, as opposed just to preferences. Konrad : Select one HIG, and stick to it? JMarc: Yes, it would be good if the HIG is good. Jürgen: I agree. At least better than inventing our own. (And these were, basically, all people involved in the first thread.) So my keeping the HIG flag high was based on the believe that this is commonly wanted. Big open question: Is this the case? Should we stick to a HIG ? If the majority thinks that no and other things (such as legacy, personal preference, etc.) are more improtant: No problem for me, either. Cheers, Konrad P.S. On the personal things: Thanks for your answer - looks like a misunderstanding, no problem.
RE: Re: menu structure
I think that either we build something based on likes/dislikes, or something based on HIGs. In the later case, I am happy to be involved, in the earlier case I will not be involved very much (but just as happy). You're right, but: - In the thread it was also mentioned that we would like to change the least as possible. - What happens if two HIGs clash ? Which one to choose ? - The application menu section in the Apple HIG is basically empty. How do we decide on what is application-specific enough to be in such a menu ? I'm really interested what your vision is on these things ? Well I can guess the second, so don't answer: stick to one HIG, because that's guaranteed to be a problem. I can send you a link if you want to look at it. :-) Not necessary, you already send it, and I looked at it, and you're absolutely right in the things you said. But unfortunately, according to Pavel (I guess), then the HIG is *. ;-). Vincent
Re: menu structure
Vincent van Ravesteijn - TNW wrote: I think that either we build something based on likes/dislikes, or something based on HIGs. In the later case, I am happy to be involved, in the earlier case I will not be involved very much (but just as happy). You're right, but: What follow are all very valid questions (and the first two remain unanswered). - In the thread it was also mentioned that we would like to change the least as possible. We cannot fulfill everything, somewhere we have to cut. If this is HIG compliance, legacy, or something else, is not on me to decide. - What happens if two HIGs clash ? Which one to choose ? The major one we decide on. So far Edwin started with Apple's (which I am naturally not opposed to), but I kept an eye on the windows HIG. For example, a Tools menu would be something it looks like people want (which is more Win than Apple, but still conforms with Apple's). Whereas Document is something that does not much conform to either one (but feel free to convince me from the opposite), and also not Gnome [1] and KDE [2]. - The application menu section in the Apple HIG is basically empty. As in 1.5, we should have that Application menu only on the Mac (where it is auto-generated by the OS). It contains typically only Preferences, About, and Quit, and Check for Updates, and is populated with more entries by the OS. For LyX I do not see much question: Certainly About, Prefs, Reconfigure, and Quit, and, if we don't have a Tools menu, probably TeX Information. How do we decide on what is application-specific enough to be in such a menu ? Does above answer that? On other platforms, Quit belongs into (KDE, Gnome and Windows HIG) File, and Preferences (plus reconfigure) in (Gnome and Windows HIG) Edit. I'm really interested what your vision is on these things ? I interpret this question mark now as typo. :) Well I can guess the second, so don't answer: stick to one HIG, because that's guaranteed to be a problem. ooops ... too late. :) Ok, ok, the issue does not have to be as black-and-white as I paint it. But I would still try to stay away from making our own HIG. I can send you a link if you want to look at it. :-) Not necessary, you already send it, and I looked at it, I know. :) Not sure how we proceed from here. /Konrad [1] http://library.gnome.org/devel/hig-book/stable/menus-standard.html.en [2] http://wiki.openusability.org/guidelines/index.php/Guidelines:Menus
Re: menu structure
John Levon wrote: - what the biggest problems are with the current structure Some statistics : first figure is the number of menu items, the second number the total menu + sub-menus + sub-sub-menus items LyX svn blank document with a table File : 17 ; 53 Edit : 17 ; 79 View : 19 ; 55 Insert : 26 ; 89 Navigate : 5 ; 11 Document : 6 ; 13 Tools : 6 Help : 13 Total menu + sub-menus = 319 items OOwriter File : 21 ; 56 Edition : 25 ; 33 View : 14 ; 38 Insert : 24 ; 56 Format : 19 ; 64 Table : 17 ; 36 Tools : 19 ; 63 Windows : 3 Help : 5 Total menu + sub-menus = 318 items Problems : 1) The number of items is very big. Do we have any room to grow ? Oowriter interface is a clone of the old Word interface that was considered a nightmare of complexity. There is somewhere an interesting blog on the Microsoft site about Office12, with different members of the Microsoft usability team explaining the problems of the old MsWord interface. 2) Our menu tree is not well balanced we have 25 % of the items in the Insert menu ; the biggest menus in OOwriter is around 20 % of the total. 3) There is IMHO useless complexity, like the 7 different preview formats. If we just drop everything except pdf with a simple parser that would run it through dvips - ps2pdf if there is pstricks or powerdot in the preamble we magically eliminate 13 items with no lost functionality (except for DVI aficionados) 4) Mathematics is a big elephant with a gigantic bottom crushing everybody. I don't have Mathematica, neither Maple, I don't write formulas in Fraktur. Mathematicians should be able to turn on a mathematician module, like chemists a chemistry module, etc... but the core of LyX should be left generic. 5) There is some dead wood. Does Fax works anymore across platforms ? 6) The version control items are for geek. It should be done through macros and then every geek can choose its favorite version control system. - why a new structure would help The Web is full of articles investigating how people navigate in a tree. It shows that if the tree is balanced with not too many levels and items are structured in a logical way, people find the good item quicker. - the guiding principles behind the design of the new structure 1) Recreate a balanced tree by exploding the Insert menu 2) The Edit menu had become something very strange 3) Isolation of a Math menu starts the path towards Activity menus. - what each of the main HIGs have to say about both the old and new setup HIG will only help us for the File, Edit maybe View and Windows menus that are standardized. After that, it is up to us to find a good structure. Cheers, Charles
Re: menu structure
On Thu, Sep 18, 2008 at 01:03:38AM +0200, [EMAIL PROTECTED] wrote: 1) The number of items is very big. Do we have any room to grow ? Oowriter interface is a clone of the old Word interface that was considered a 3) There is IMHO useless complexity, like the 7 different preview formats. If we just drop everything except pdf with a simple parser that would run aficionados) 4) Mathematics is a big elephant with a gigantic bottom crushing everybody. I don't have Mathematica, neither Maple, I don't write formulas in Fraktur. 5) There is some dead wood. Does Fax works anymore across platforms ? 6) The version control items are for geek. It should be done through macros and then every geek can choose its favorite version control system. All of these are true of any potential re-org. You want to remove some menu items into optional LyX modules: great (old) idea, but doesn't need a menu re-org. Please do this, it would be very cool. - why a new structure would help The Web is full of articles investigating how people navigate in a tree. It shows that if the tree is balanced with not too many levels and items are structured in a logical way, people find the good item quicker. I'll be very impressed if you can find a balanced menu layout that makes sense logically, and is significantly better than the existing one :) - the guiding principles behind the design of the new structure 1) Recreate a balanced tree by exploding the Insert menu 2) The Edit menu had become something very strange 3) Isolation of a Math menu starts the path towards Activity menus. I'd be interested to see what you're suggesting, though I believe it should be incremental during the development period (done by release, of course). Could you further explain point 2) ? Somewhere in the archives I have a detailed explanation of why the Edit menu is the way it is. regards, john
Re: menu structure
Konrad Hofbauer wrote: Not sure how we proceed from here. hmm if we are in black hole, then lets try to get little back in the discussion. what was the reason to the menu change? imho the fact that users(=we) are discontent with the current menu. so the first thing, the end result has to be something less annoying than the current state; thats why the question of legacy really arises - if the changes are going to upset more then the current state there is no point to change anything. sorry if i'm just repeating what has been said, but: 1. is there some consesus/do we have properly mapped what is exactly wrong with the menu from the users point of view? (this would need some kind of questionary) 2a. do these things need big restructuralisation or 2b. are these somehow manageable through simple changes? i tend to say that if we are not able to agree on 1 then there is no point of changing anything, because except hig committee most people will be only annoyned by learning something new, possibly unlogical in their view. imho the hig applies mainly in case 2a. and also as a defense on threads starting hey gyus i want this item move over there once menu is stable (like now). pavel
RE: menu structure
konrad wrote: > Edwin (and others), > > great thanks for starting to work on this! thanks for having a look as well... > I have a number of suggestions for changes, strictly based on > the HIG [1] (except those sentences starting with IMO). just as a side note; i think it is good to have some directions, but i don't think we should treat the apple hig as the holy bible (personally i like apples, but as a fruit). as i see it many of these ui design decisions (also in the apple hig) are as much about convention as about logic. apple is one convention, windows another. lyx runs on many platforms so we should try something which people on all platforms recognize and don't get lost in... but let's see: > Instead of having different ui/inc-files circulating around, > I think it makes more sense if you maintain the "master" > version and include from my suggestion what you deem > appropriate. OK ??? sure, but we need to reach some consensus on the list (and solve the shortcuts issue) > File *** > > New Window > New Tab > New File > > ... > > IMO: Yes, it looks a bit clustered with all the different New > and Close, but this is what they do (and also removes current > confusion). current as in lyx 1.5? or current as in the file i send? i think in the latter there is not much confusion concerning file and windowing/view stuff... > Concerning Import/Export: unrelated to menus... > *** Edit *** > > According to HIG, no separator above Select All. ok > Move Paragraph Up/Down this is for the edit menu i think, it is about ordering/contents and not formatting > and Text/Paragraph Styles would more > be something > for a (HIG-recommended) Format-Menu, but we don't have that > since these four things would be the only entries (?). that's indeed a possibility > *** Window vs. View *** > According to HIG there should be: > 1) a VIEW menu for all what concerns appearance WITHIN a > window and [6] > 2) a WINDOW menu for managing the multiple windows. [7] i think i prefer the current (ie last version i send). i realize that it put these things together, but it makes a stricter separation between the document and the view/window. the reason why i don't like this view menu, is that "view" is a verb and a noun and this leads to confusion (see below). imo of course. > > *** Window *** > According to HG [5] putting Source and Navigation here is perfect! > I would call them (to be consistent): > "View Source" and "View Navigation" an illustration of why i don't like this "view" menu too much. it is confusing, is "view on the document" or stuff you want to "view". if we would want to insist on similar naming i would also prefer "navigation panel" and "source panel" > But all other items do NOT belong here according to HIG, but > into a View menu. on apple... > What also belongs here but we do not have: > Minimize > Maximize shrug > *** View *** again, i don't really like this myself > So this is a new menu following [6]. I suggest: > > Open All Insets > Close All Insets note that this is document specific. so is are we in a document menu or a view menu. confusing if you ask me. another reason why i am not a fan of a "view" menu... > *** Document *** > > There is nothing left for this menu, and the HIG give no > indication whatsoever that we should have this. but document is less ambigous than view... > *** Navigate *** > > Clearly an application-specific menu, everything fine here. > Except: A second level of sub-menus is forbidden. (p.174) > Suggestion: Just put all the lists on the first level (and > group them with a spearator), with the items in the sub-menug. this will result in menu which is very long. try this with the user guide in fact, i would drop this navigate menu. the navigation panel is much more convenient. we could think of a adding a navigate toolbar with buttons for next section, note, table and the bookmarks... > *** Table *** > Left/Center/Right/Top/... miss a verb. > But: see "Format", I would move it there. a possibility indeed > *** Format *** > According to HIG this menu should be there [9]. > > I would suggest: > > Capitalize > Uppercase > Lowercase > -- > Customized Text Style ... > Dissolve CharStyle (what is this ???) > -- > Paragraph Style ... got no idea what that means either;-) > Move Paragraph Up > Move Paragraph Down for the edit menu > -- > Table > (all into sub what is in Table MainMenu now) yes > *** Math *** > Looks good. It could go into Format as well, but it is too > large for a sub-menu (and would have sub-sub-menues then). > According HIG it is OK to promote it to a full menu in such a > situation. i agree > *** Insert *** > Looks good this is a bit of a mess i think (it is very full with little grouping), but i do not really see how we can improve it... >, except: > > IMO Footnotes and marginal notes are Notes, and we have a > submenu called Note, so they should be there. A note is a >
Re: menu structure
Hi Edwin, thanks for your comments. leuven edwin wrote: konrad wrote: just as a side note; i think it is good to have some directions, but i don't think we should treat the apple hig as the holy bible (personally i like apples, but as a fruit). as i see it many of these ui design decisions (also in the apple hig) are as much about convention as about logic. apple is one convention, windows another. lyx runs on many platforms so we should try something which people on all platforms recognize and don't get lost in... This is not just a side note, but I think the most important priciple question! 1) I think it was mostly agreed on the earlier discussion (by those who contributed), that we should stick to one HIG. So I would indeed say that the HIG (whichever we use) is the holy bible. This is the wrong place to put personal preferences, because people have different preferences. We should try to stick as much as possible to the HIG. If you do not agree to this, then for me the discussion ends here. (No rudeness meant here - I am willing to discuss how to interpret a HIG and which way conforms most to it, but unfortunately I do not have the time to discuss personal preferences, especially by email.) * 2) You cited in your proposal Apple's HIG, which I think is a well thought one (because Apple a) does in general not care too much about legacy and b) has pretty good usability). Would you have cited Vista's HIG, then I would have used that. but let's see: Instead of having different ui/inc-files circulating around, I think it makes more sense if you maintain the "master" version and include from my suggestion what you deem appropriate. OK ??? sure, but we need to reach some consensus on the list (and solve the shortcuts issue) File *** New Window New Tab New File ... IMO: Yes, it looks a bit clustered with all the different New and Close, but this is what they do (and also removes current confusion). current as in lyx 1.5? or current as in the file i send? i think in the latter there is not much confusion concerning file and windowing/view stuff... I meant current as in what I proposed. In the file you sent (maybe also in the standard-ui) "Close" does the wrong thing - it commonly closes the view, not the file. Concerning Import/Export: unrelated to menus... *** Edit *** According to HIG, no separator above Select All. ok Move Paragraph Up/Down this is for the edit menu i think, it is about ordering/contents and not formatting ok. and Text/Paragraph Styles would more be something for a (HIG-recommended) Format-Menu, but we don't have that since these four things would be the only entries (?). that's indeed a possibility *** Window vs. View *** According to HIG there should be: 1) a VIEW menu for all what concerns appearance WITHIN a window and [6] 2) a WINDOW menu for managing the multiple windows. [7] i think i prefer the current (ie last version i send). i realize that it put these things together, but it makes a stricter separation between the document and the view/window. the reason why i don't like this view menu, is that "view" is a verb and a noun and this leads to confusion (see below). imo of course. But there is a View menu everywhere - in the XP HIG, Vista HIG, Apple HIG, Wordpad, Office 2003, ... Don't refuse just because you don't like it. *** Window *** According to HG [5] putting Source and Navigation here is perfect! I would call them (to be consistent): "View Source" and "View Navigation" an illustration of why i don't like this "view" menu too much. it is confusing, is "view on the document" or stuff you want to "view". see HIG. like it or not. if we would want to insist on similar naming i would also prefer "navigation panel" and "source panel" If it is under window, then it must have a verb. see HIG. But all other items do NOT belong here according to HIG, but into a View menu. on apple... and windows. What also belongs here but we do not have: Minimize Maximize shrug *** View *** again, i don't really like this myself which it isn't about. sorry, maybe introduce next time such a proposal as "this is what I like" (then there is no right or wrong), but if you introduce it as "this is following apple's HIG" ... (also maybe I misunderstood that). So this is a new menu following [6]. I suggest: Open All Insets Close All Insets note that this is document specific. I did not know that, I see know. It should not be like this (i.e. Inset states should be independent in multiple views IMO), but this is another topic... so is are we in a document menu or a view menu. confusing if you ask me. another reason why i am not a fan of a "view" menu... *** Document *** There is nothing left for this menu, and the HIG give no indication whatsoever that we should have this. but document is less ambigous than view... But view is standard in the three
RE: menu structure
> > but let's see: attached the reworked menu, following most of your suggestions > But there is a View menu everywhere - in the XP HIG, Vista > HIG, Apple HIG, Wordpad, Office 2003, ... so now possibly also soon in lyx... > Don't refuse just because you don't like it. that's what all religious nutcakes say, but... ...as a proof of my openmindedness, see attached > >> Open All Insets > >> Close All Insets > > > > note that this is document specific. > > I did not know that, I see know. It should not be like this > (i.e. Inset states should be independent in multiple views > IMO), but this is another topic... collapsed status is also saved in the document (like it or not), so i have put this in the file menu for now > >> *** Navigate *** > >> Except: A second level of sub-menus is forbidden. (p.174) > >> Suggestion: Just put all the lists on the first level (and > >> group them with a spearator), with the items in the sub-menu. > > > > this will result in menu which is very long. try this with the user > > guide > > I see. Try it with Intro.lyx, and it looks odd. not sure what you mean. another thing is that this is hardcoded so it's probably not going to change soon. then again, we could still consider the following: > in fact, i would drop this navigate menu. the navigation > panel is much more convenient. > we could think of a adding a navigate toolbar with buttons > for next section, note, table and the bookmarks... > But then let us call the Note-submenu something different (Comment ?). > Because the "Greyed Out" does show in the output. Also, we > should unify the naming of this three Comment items. i never use this, perhaps others have suggestions? > Please decide on how you want to proceed: > a) based on what you think makes most sense (i.e. what you like) OR > b) based on a holy-bible-HIG. that still open for discussion i suppose, and not only up to us. but thanks for your input. so the attached has a view menu for the sake of hig-ness, but note it is *very* empty. it has only 2 items: toolbars and fullscreen. as far as i am concerned we would put these in the application menu and be done with it. for the rest it is a BIG improvement on the current menu i think. i urge everybody to give the attached a try ed. hig.ui Description: hig.ui hig.inc Description: hig.inc
RE: menu structure
> [4] Our document settings are file-specific parameters, saved with the
> document, so it is IMO very similar to the Page Setup-item in the HIG:
> Page Setup... . Opens a dialog for specifying printing parameters such
> as paper size and printing orientation. These parameters are saved
with
> the document.
Good to see that two people have stand up already...
IMHO
{
Maybe, it is a HIG interpretation thing, but I'm seriously doubting that
the HIG says that content-related stuff like the "Document settings..."
must be in the File menu. Things like page setup do not influence the
content of the document in any way, besides how it is printed.
This also holds for the Statistics item, it is really not just a file
statistic. It is something that is used while generating content,
something that influences whether I can add another sentence to the
abstract or not. It also counts words in a selection. So, it is not
really a file statistic.
In conclusion, the interpretation of the argument that it is
file-specific and that it is saved with the document might be
reconsidered, because I feel that this only holds for file-specific
options that do not influence the content in any way.
Last, I agree that it is a good approach to look at independent,
well-thought HIGs, but don't forget the other constrictions that were
raised in the discussion last days. For example, LyX users are used to
having a Document->Settings... Item. They will be disturbed if they have
to look for one of the most important menu items.
I dreamt last night of a Document menu with the grouped tools (They
really must be next to each other, otherwise I will be looking for them
over and over again).
DOCUMENT MENU:
- Spellchecker, that checks my document for spelling errors,
- Thesaurus, just because it is next to the Spellchecker,
- Statistics, counting words in my document or in specific parts of my
document,
=
- Branching, all options in the document->settings dialog are stored in
the document except branching information, that is filtered out by LyX
itself, so it deserves an item on its own.
=
- Settings..., one of the most important menu items IMO, which users
will find when it's in the Document menu, .. Oh and it does of course
say something about the document.
}
Please consider this,
Vincent
RE: menu structure
as in attached menu order: file, edit, format, insert, math, go to, typeset, window, document, application, help toolbars is in application fullscreen in window i like this myself (if I can say that..) hig2.inc Description: hig2.inc hig2.ui Description: hig2.ui
Re: menu structure
Edwin, "for the sake of hig-ness" - I guess that means I am higgy? Quite possible. :-) About the open/close windows, tabs, etc., and independent of the menue discussion, I don't quite get what does what (esp. the "Close tab group"). Should that not be a simple "Close tab"-functionality? leuven edwin wrote: but let's see: attached the reworked menu, following most of your suggestions Looks very higgy. :) But there is a View menu everywhere - in the XP HIG, Vista HIG, Apple HIG, Wordpad, Office 2003, ... so now possibly also soon in lyx... Don't refuse just because you don't like it. that's what all religious nutcakes say, but... ...as a proof of my openmindedness, see attached Open All Insets Close All Insets note that this is document specific. I did not know that, I see know. It should not be like this (i.e. Inset states should be independent in multiple views IMO), but this is another topic... collapsed status is also saved in the document (like it or not), so i have put this in the file menu for now. Conceptually one can argue for one or the other. But just because something is stored in the document, does not mean it needs to be in the File-menu. IMO (!!! -> don't care about it!) I would still see it as a classical element of the View-Menu. That it also affects the appearance in other windows (not just the current), well ... too bad. *** Navigate *** Except: A second level of sub-menus is forbidden. (p.174) Suggestion: Just put all the lists on the first level (and group them with a spearator), with the items in the sub-menu. this will result in menu which is very long. try this with the user guide I see. Try it with Intro.lyx, and it looks odd. not sure what you mean. another thing is that this is hardcoded so it's probably not going to change soon. Right. It is OK as it is right now, I would say. then again, we could still consider the following: in fact, i would drop this navigate menu. the navigation panel is much more convenient. Personally, I never use the Navigate-Menu in 1.5 at all, so I would not miss it. But don't know what other people do ... we could think of a adding a navigate toolbar with buttons for next section, note, table and the bookmarks... Sounds good to me! But then let us call the Note-submenu something different (Comment ?). Because the "Greyed Out" does show in the output. Also, we should unify the naming of this three Comment items. i never use this, perhaps others have suggestions? How about Comment > LyX Comment LaTeX Comment Printed Comment (or Typeset Comment) Please decide on how you want to proceed: a) based on what you think makes most sense (i.e. what you like) OR b) based on a holy-bible-HIG. that still open for discussion i suppose, and not only up to us. but thanks for your input. so the attached has a view menu for the sake of hig-ness, but note it is *very* empty. it has only 2 items: toolbars and fullscreen. as far as i am concerned we would put these in the application menu and be done with it. According to HIG, Split Left/Right and Split Top/Bottom clearly belong into View, not Window, I would suppose. (And with the Open/Close Insets discussed above, the Menu size would be just right.) About the "Application"-menu: I am not sure if what I see here (on the Mac) is what you meant me to see, and how it looks on windows/linux. Historically (and currently, and hopefully also in the future), the Mac has a few commands in a LyX-menu (augmented by other commands from the OS), that affect the application. That should be: 1) About LyX 2) Preferences 3) Reconfigure 4) TeX Information (that could be in Windows though) 5) Quit I do NOT think we should have a similar "Application" menu on windows/linux, but but 1) in Help, and 5) at the bottom of the File menu (I think every windows and gnome app has that). 2) 3) 4) are problematic. Gnome has the Preferences always in the Edit-Menu. I would probably put 2) 3) 4) into the File menu at the bottom, but I can see why one would object. An "Application" menu, is that frequently done in other apps? for the rest it is a BIG improvement on the current menu i think. Very much agreed! I hope some others will look at it, too! /Konrad
RE: menu structure
> as in attached Sort of.. ;-) > i like this myself (if I can say that..) I like it too, but... (just being constructive) - it is very sneaky to remove the View menu again.. Moving all items from the Window menu into the View menu would ALSO be an option... - The File->New Window and File->Close Window don't deserve to be the first items. All applications I know have a first item called "New (File)" and the first item after the first separator "Close (File)" *. The new/close window options are hardly used (just a guess) and are now really in the way when I want a new or to close a file (because of habit/intuition). * This of course only holds when applications can create new files or open them. I know that IE has a first item New->Window, but that is a totally different application. - Following 'my' logic about the File menu and content-related stuff, the Compressed item should be in the File menu. It has nothing to do with the content, just with how it is saved. Would it be an option to insert between "Save all.." and "Revert to saved" (or maybe one below) an item "Save compressed.." ? - What is the difference between the Latex Source Panel, Navigation panel and Toolbars ? Shouldn't these be next to each other ? Preferably in a View menu, otherwise in a Window menu. ? Vincent
Re: menu structure
Vincent van Ravesteijn - TNW wrote: Maybe, it is a HIG interpretation thing, but I'm seriously doubting that the HIG says that content-related stuff like the "Document settings..." must be in the File menu. Correct. (but I still think it is the right place) Things like page setup do not influence the content of the document in any way, besides how it is printed. This also holds for the Statistics item, it is really not just a file statistic. It is something that is used while generating content, something that influences whether I can add another sentence to the abstract or not. It also counts words in a selection. So, it is not really a file statistic. Indeed. (But you could say the same for Document. IMO File and Document is the same thing.) In conclusion, the interpretation of the argument that it is file-specific and that it is saved with the document might be reconsidered, because I feel that this only holds for file-specific options that do not influence the content in any way. Very open to this. Last, I agree that it is a good approach to look at independent, well-thought HIGs, ... Can this be our main-line-of-argumentation? I think it is the only way how to come up with something consistens. > For example, LyX users are used to having a Document->Settings... Item. They will be disturbed if they have to look for one of the most important menu items. IMO - no, no, no. If we start to care about legacy, nothing good will come out. I dreamt last night of a Document menu with the grouped tools (They really must be next to each other, otherwise I will be looking for them over and over again). DOCUMENT MENU: - Spellchecker, that checks my document for spelling errors, - Thesaurus, just because it is next to the Spellchecker, - Statistics, counting words in my document or in specific parts of my document, = - Branching, all options in the document->settings dialog are stored in the document except branching information, that is filtered out by LyX itself, so it deserves an item on its own. = - Settings..., one of the most important menu items IMO, which users will find when it's in the Document menu, .. Oh and it does of course say something about the document. } 1) Can you please define what the Document menu is good for (in a future-compatible abstract way)? Any HIG? 2) You are on Windows? The list of things you gave for your "Document" menu is mostly what Word and friends have as "Tools" menu? In fact, such a Tools menu is part of the XP/Vista HIG. So if we have such a group of things, let us at least call it "Tools". We start to mix HIG's though. /Konrad
Re: menu structure
Vincent van Ravesteijn - TNW wrote: - it is very sneaky to remove the View menu again.. Moving all items from the Window menu into the View menu would ALSO be an option... If you propose something like this, then please propose a LyX-Menu-HIG. - The File->New Window and File->Close Window don't deserve to be the first items. All applications I know have a first item called "New (File)" and the first item after the first separator "Close (File)" *. The new/close window options are hardly used (just a guess) and are now really in the way when I want a new or to close a file (because of habit/intuition). I like it though the way it is - because it is logic (all opens and closes in one group). * This of course only holds when applications can create new files or open them. I know that IE has a first item New->Window, but that is a totally different application. Same for (cross-platform) firefox and safari. But of course, your argument holds. - Following 'my' logic about the File menu and content-related stuff, the Compressed item should be in the File menu. It has nothing to do with the content, just with how it is saved. Would it be an option to insert between "Save all.." and "Revert to saved" (or maybe one below) an item "Save compressed.." ? I agree! - What is the difference between the Latex Source Panel, Navigation panel and Toolbars ? Shouldn't these be next to each other ? Preferably in a View menu, otherwise in a Window menu. ? That Panels are seen (following the HIG) as separate windows, whereas Toobar is a within-the-window option. /Konrad
Re: menu structure
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > Maybe, it is a HIG interpretation thing, but I'm seriously doubting that > the HIG says that content-related stuff like the "Document settings..." > must be in the File menu. Things like page setup do not influence the > content of the document in any way, besides how it is printed. I do not think either that it is a good idea. The idea as I see it is to put the things that directly affect margins or paper size (because it is near to File>Print), but certainly not all document settings. > In conclusion, the interpretation of the argument that it is > file-specific and that it is saved with the document might be > reconsidered, because I feel that this only holds for file-specific > options that do not influence the content in any way. I think it is related to actions of saving the file to disk or to printer. In this sense, modifying paper size might be good (like changing format in Save As) but the rest is not. JMarc
Re: menu structure
Konrad Hofbauer <[EMAIL PROTECTED]> writes: >> For example, LyX users are used to >> having a Document->Settings... Item. They will be disturbed if they have >> to look for one of the most important menu items. > > IMO - no, no, no. If we start to care about legacy, nothing good will > come out. Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. JMarc
Re: menu structure
leuven edwin <[EMAIL PROTECTED]> writes: >> I did not know that, I see know. It should not be like this >> (i.e. Inset states should be independent in multiple views >> IMO), but this is another topic... > > collapsed status is also saved in the document (like it or not), so > i have put this in the file menu for now I would not do that. File menu is more for physical state of the document (so I guess Compressed can belong there). If you do that, why not put "Insert Table Float" too??? JMarc
Re: menu structure
leuven edwin wrote: i like this myself (if I can say that..) I don't. Which HIG does it follow? /Konrad
RE: menu structure
>> collapsed status is also saved in the document (like it or not), so >> i have put this in the file menu for now > > I would not do that. File menu is more for physical state of the > document (so I guess Compressed can belong there). If you do that, why > not put "Insert Table Float" too??? hey don't shoot the messanger! just following the hig...
Re: menu structure
leuven edwin <[EMAIL PROTECTED]> writes: >>> collapsed status is also saved in the document (like it or not), so >>> i have put this in the file menu for now >> >> I would not do that. File menu is more for physical state of the >> document (so I guess Compressed can belong there). If you do that, why >> not put "Insert Table Float" too??? > > hey don't shoot the messanger! just following the hig... I only followed the discussion with an eye. Could some nice soul point me to the relevant HIG part? JMarc
RE: Re: menu structure
> > Maybe, it is a HIG interpretation thing, but I'm seriously doubting > > that the HIG says that content-related stuff like the "Document settings..." > > must be in the File menu. > > Correct. (but I still think it is the right place) > > > Things like page setup do not influence the content of the document in > > any way, besides how it is printed. > > > > This also holds for the Statistics item, it is really not just a file > > statistic. It is something that is used while generating content, > > something that influences whether I can add another sentence to the > > abstract or not. It also counts words in a selection. So, it is not > > really a file statistic. > > Indeed. (But you could say the same for Document. IMO File and Document > is the same thing.) > Well, I just wanted to make a distinction between content-related and content-unrelated items. (And I chose Document, because LyX has already a Document menu and I do care about legacy, see below) > > Last, I agree that it is a good approach to look at independent, > > well-thought HIGs, ... > > Can this be our main-line-of-argumentation? > I think it is the only way how to come up with something consistens. > > > For example, LyX users are used to > > having a Document->Settings... Item. They will be disturbed if they > > have to look for one of the most important menu items. > > IMO - no, no, no. If we start to care about legacy, nothing good > will come out. Again, I do care about legacy; LyX deserves its own identity (in case of doubt). > 1) Can you please define what the Document menu is good for (in a > future-compatible abstract way)? Any HIG? Can't, guilty as charged. > 2) You are on Windows? The list of things you gave for your "Document" > menu is mostly what Word and friends have as "Tools" menu? In fact, > such a Tools menu is part of the XP/Vista HIG. So if we have such a > group of things, let us at least call it "Tools". We start to mix > HIG's though. Indeed, adjusting interpretation, deviating slightly as not everything might be captured in the HIG, and the legacy thing of course. As for the File menu, I can reason the same for the Edit menu... (and you might look in the HIG whether this is true/false or open for interpretation). Besides the Change tracking and Spellchecker items, all items in the Edit menu are only pure 'management'-like items. These items have nothing to do with what is being edited, only moving around chunks of text/images/newlines/insets/etc. In contrary, the Spellchecker look at what is being processed, whether it is spelled correctly. The Thesaurus look at how the user could say it differently, maybe better, maybe enrichening the language use of the writer. Last, change tracking displays (maybe) another opinion of another author, it represents enhancements. IMO it is much more than administration (but this might be discussable). - Statistics / Document Settings may be moved somewhere else, because they are content-related, - Spellchecker / Thesaurus may be moved, because they relate to the content of the text that is being processed. And because the common divisor of these problem cases is that they are content-related, I put them together in a content-related-menu aka Document menu (from the viewpoint of legacy I think this is a good name, but this might be discussable.) That's my reason for the Document menu. What if the HIG doesn't have the correct place for these items...? > /Konrad Vincent
RE: menu structure
> - it is very sneaky to remove the View menu again.. Moving all items > from the Window menu into the View menu would ALSO be an option... not sneaky, i just moved the 2 items in the view menu. the window menu was much fuller so i makes sense not to name it view. of course we could s/window/view/ > - The File->New Window and File->Close Window don't deserve to be the > first items. hig guidelines according to konrad > The new/close window options are hardly used (just a guess) and are now > really in the way when I want a new or to close a file (because of > habit/intuition). again, hig guidelines. i can see a rationale for moving them down... > - Following 'my' logic about the File menu and content-related stuff, > the Compressed item should be in the File menu. sure > Would it be an option to insert between "Save all.." and "Revert to saved" > (or maybe one below) an item "Save compressed.." ? not atm since it is a toggling menu item > - What is the difference between the Latex Source Panel, Navigation > panel and Toolbars ? Shouldn't these be next to each other ? Preferably > in a View menu, otherwise in a Window menu. ? in the window menu according to the hig... ed.
Re: menu structure
Jean-Marc Lasgouttes wrote: Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has "Properties" in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. What is the difference between file and document in the first place ??? I am not quite convinced about Document==Content. And even if we do so, it is not clear/logical to the user. /Konrad
Re: menu structure
Konrad Hofbauer wrote: Jean-Marc Lasgouttes wrote: Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has "Properties" in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. Forgot (sorry for the noise): And both don't have any more document-level settings, as far as I can see. /Konrad
Re: menu structure
Konrad Hofbauer <[EMAIL PROTECTED]> writes: > Word 2003 has the Page Setup in File, OO has "Properties" in File. > Both of them don't have a Document menu. Both have (a Windows-HIG) > Tools menu. > What is the difference between file and document in the first place ??? In OO File>Properties is not very conclusive... I do not have word 2003 here, but what I remember is that only page layout can be changed in File menu. In our document settings, we other style-related entries that fit in Format menu in word. > I am not quite convinced about Document==Content. And even if we do > so, it is not clear/logical to the user. I understand you concern. But I strongly dislike putting all in File. JMarc
Re: menu structure
[EMAIL PROTECTED] wrote: leuven edwin <[EMAIL PROTECTED]> writes: collapsed status is also saved in the document (like it or not), so i have put this in the file menu for now I would not do that. File menu is more for physical state of the document (so I guess Compressed can belong there). If you do that, why not put "Insert Table Float" too??? hey don't shoot the messanger! just following the hig... I only followed the discussion with an eye. Could some nice soul point me to the relevant HIG part? That is my job ;-) but I disagree here. In my interpretation of the HIG it belongs into View: "The View menu provides commands that affect how users see a window’s content; it does not provide commands to select specific document windows to view or to manage a specific document window. Commands to organize, select, and manage windows are in the Window menu." And about the discussion if we should merge View and Window - menu: Every application I seen on my desktop, all Apple apps, all Mozilla apps, OpenOffice, Word 2003 (on XP), ... have a View AND a WINDOW menu, and there is a rationale behind it. Neither Word, OO or any of my Text-Editors has a Document-menu. /Konrad
