From: David H. <dh...@ma...> - 2003-05-11 02:02:36
|
I've subscribed to this mailing list because I think that InterfaceWM -- being fairly young -- is in a unique position to overcome the flaws that other WMs have succumbed to. Ok, I've made a OpenOffice (Impress) presentation file for my ideas on what a UI should look like. You can download it from: http://home.rochester.rr.com/tweak/Desktop.sxi http://home.rochester.rr.com/tweak/Desktop.png It's available in both sxi (OpenOffice Impress) and PNG format to make sure everyone can see it. Hopefully, you all have OpenOffice Impress, which will also allow you to modify this with modded suggestions. But, if not, at least you can view it as a PNG with your browsers. I realize that many of these features aren't strictly the business of the WM, but other things can be built around and with the WM to make them realities. Ok, so let me explain it: * First idea. Minimize customization possibilities. I know many like diddling with customization, but it's really mostly a waste of user time. Customization for the most part means that the developers couldn't be bothered to get it right, so let the user's figure it out. It also means that it's harder to support your program. I think the level of customization allowed in WindowMaker is approximately suitable, though perhaps a little bit less (explained later). Other customization should be just for performance and RAM purposes...obvioiusly different computers have different needs. * There's no "traditional desktop". That's because traditional desktop's -- which occupy the root window -- are retarded. Do you really like meisering around trying to click on a tiny 48x48 icon (some of which might not even be clickable), with the possibility of moving it instead? I suggest that as a replacement, the entire desktop be like a pie-menu of 8 of the programs you've used recently. This has the effect of creating huge buttons (which is good, according to Fitss' law). I suggest that these 8 recently used programs have pie-buttons where the size is positively correlated to how often they are used. So the most used programs -- which is, lol, porn) -- would have the biggest buttons. I also suggest making more and more used programs progressively warmer colors, and less and less used programs progressively cool colors. (this is because warmer colors stick out, cooler colors recede). Furthermore -- and I didn't show this in the drawing -- it should take advantage of corner-ease of use, with the option for RH and LH people. For RH people, the easiest corner to reach (in order of fastest to slowest) are: 1. Bottom right corner. 2. Top left corner 3. Top right corner 4. Buttom left corner Of course, it's reversed for LH people, and everything I mention would need to be mirror-imaged for LH people. Thus, for right handed people, the most used programs should be in the bottom right hand corner of the screen, and the lesser used ones progressively in the other corners counter-clockwise. * The programs menu for each application should be at the most clickable location -- the current pixel. This is what WindowMaker does, and it's the right way to do things. * All apps should share a common toolbar bleeding into the top of the screen. This takes advantage of the mile-high menu-bar effect. It's just annother application of Fitts' law. It's real easy to slam your mouse up to the top of the screen. * While we're on toolbars, programs should have few buttons. Programs like OpenOffice and MS Word with a trillion toolbar buttons are not good (how often do you actually use all of those buttons?). Furthermore, as an idea, it'd be great if the programs had a way of collecting data about what toolbar buttons and menu options are used the most, so programmers can make those one's buttons. * Develop some technogical way to force programmers writing progs for InterfaceWM to make the toolbar bleed into the top edge of the screen. People who put the toolbar exactly 1 pixel from the top of the screen -- so that it's safely useless in Fitss terms -- need to be clobbered with a monitor. * The dock would bleed into the left hand side of the screen. It would always be obscureable by default. That D you see at the bottom left hand side of the screen would be a trigger (which would be the pixel at the far lower left corner of the screen) that would bring the dock to the foreground temporarily. It would stay on the foreground until you launched and application or clicked on another window. The dock trigger is on the 5th most clickable pixel on the screen. * Also in regards to the dock, since the pixels towards the upper left corner of the screen are increasingly easier to click for RH-people, the more often used progs should be on the upper portion of the dock. * Root window trigger at far upper left corner of screen. This is the 2nd most clickable pixel on the screen. * Window list trigger at far upper right corner of screen. This is the 3rd most clickable pixel on the screen. * Trashcan trigger at far lower right corner of screen. 4th most clickable pixel. * All apps would share a common scrollbar, which would bleed into the far right hand side of the screen. The huge buttons you see are there for a reason -- larger buttons are easier to click on. True, you'd give up a little bit of control in scrolling through manually, but so what? Most people never use that anyways. * Allow for pop-up folders and menus to be stuck to the bottom of the screen, and fly up when clicked on. (no animation). * Any animations for opening, closing, minimizing, etc, should be kept to a simple two dotted lines. * For submenu navigation -- we need a V-buffer space, so the submenu remains open so long as the person is moving 2 pixels over for every pixel down or up. This way, people don't have to navigate a narrow rift when navigating submenus. Furthermore, dotted lines should display the calculated critical path as the user moves the mouse forward. May want to have hyperbolic V-buffer space: after all, as the user gets closer and closer to the submenu, it is more and more likely that she wants to go into it. * Despite what my picture shows, no transparency. That's merely for illustration purposes. * It's about time we got the ability to automatically arrange windows. I don't like manually sizing all my windows. Provide options for cascade, tile vertically, tile horizontally, and other possible arrangements of windows. * Marry function to appearance. OSX and many WM themes are outrageous examples of how function has been completely divorced from function. Things that are draggable should appear draggable, and have a high-resistence appearance. Things that are clickable should appear clickable, and be inversely topological to our hands or fingers. Things that aren't clickable shouldn't appear clickable. Welp, those are my ideas. --Dave Heinrich |
From: Eric C. <ra...@ch...> - 2003-05-12 04:41:40
|
On Sat, May 10, 2003 at 10:02:26PM -0400, David Heinrich wrote: > Ok, so let me explain it: > > * First idea. Minimize customization possibilities. I know many like > diddling with customization, but it's really mostly a waste of user time. > Customization for the most part means that the developers couldn't be > bothered to get it right, Assuming there IS a "right" (which I believe there is not). > so let the user's figure it out. It also means > that it's harder to support your program. That's true. Not sure what to do about that one... > * There's no "traditional desktop". That's because traditional desktop's > -- which occupy the root window -- are retarded. I'd kind of agree, except that occasionally I do find desktops useful, and I wouldn't couch their deficiencies in such terms. > Do you really like > meisering around trying to click on a tiny 48x48 icon (some of which might > not even be clickable), with the possibility of moving it instead? I'm really confused by this; what do you mean? One thing I can say is that I don't consider 48x48 a "tiny" size for an icon, and who says desktop icons have to be 48x48 anyway? Also, why would the icons not be clickable? > I > suggest that as a replacement, the entire desktop be like a pie-menu of 8 > of the programs you've used recently. This has the effect of creating huge > buttons (which is good, according to Fitss' law). Well, I like the idea of popup pie menus, but the idea of a huge pie menu taking up the root window seems even worse to me estheticly than to have it occupied by a desktop. > I suggest that these 8 recently used programs have pie-buttons where the > size is positively correlated to how often they are used. So the most used > programs -- which is, lol, porn) -- would have the biggest buttons. I also > suggest making more and more used programs progressively warmer colors, > and less and less used programs progressively cool colors. (this is > because warmer colors stick out, cooler colors recede). The color/size idea is pretty interesting (that's "interesting" with a good connotation). :) > Furthermore -- and > I didn't show this in the drawing -- it should take advantage of > corner-ease of use, with the option for RH and LH people. I love the idea of "hot" areas in the corners. I'm not sure if they should have to be clicked, or just touched by the pointer. > For RH people, > the easiest corner to reach (in order of fastest to slowest) are: > > 1. Bottom right corner. > 2. Top left corner > 3. Top right corner > 4. Buttom left corner Seems somehow appropriate that Microsoft put its Start button there :) > Of course, it's reversed for LH people, and everything I mention would > need to be mirror-imaged for LH people. About handedness: I'm not disputing this claim (directly at least), but I ask you what the basis for this assertion is. I've heard several people online claim that such-and-such is easier for right-handers to reach, whereas so-and-so is easier for left-handers to reach; but I don't know what the research or reasoning is that backs this up. To me, a right-hander, it is equally easy, for instance, to have my window control buttons on the right side like Windows, on the left side like OSX, or spread among both sides. I don't personally see how handedness enters into it (although I am open to any explanation of the reasoning or research behind it, as I said). Also, it would be nice for the handedness issue to be qualified -- when you speak of left-handed people, are you assuming they have their mouse on the left side of their keyboard? Or on the right? Or either? > Thus, for right handed people, the most used programs should be in the > bottom right hand corner of the screen, and the lesser used ones > progressively in the other corners counter-clockwise. > > * The programs menu for each application should be at the most clickable > location -- the current pixel. This is what WindowMaker does, and it's the > right way to do things. I love having popup menus available at any location on the screen. However, I personally prefer the idea of pop-up menus giving some kind of priority to actions which are *specific* to the current context. I'm not sure what form the "priority" would take; it might be that actions associated with the current context would be spacially closest to the cursor, or maybe they could be bigger targets, or your color idea, etc. I stress, however, that context-specific actions would not be the *only* actions on the popup menu*, as is the case in Windows, MacOSX, KDE, GNOME, etc., because I find it very convenient to be able to perform actions performed with the application or document in general, not just objects inside them, all from a popup menu. * Yes, I realize that a lot of apps *do* put non-context-specific entries in their "context" menus, but the *ideal* seems to be to put only context-specific entries in them. > * All apps should share a common toolbar bleeding into the top of the > screen. This takes advantage of the mile-high menu-bar effect. Interesting. Tell me more. What would the toolbar consist of? Would the toolbar change any time you switched apps? Would there be a set of buttons *always* on the bar, plus some others that individual apps would add? > * While we're on toolbars, programs should have few buttons. Programs like > OpenOffice and MS Word with a trillion toolbar buttons are not good (how > often do you actually use all of those buttons?). No argument with that! > Furthermore, as an idea, > it'd be great if the programs had a way of collecting data about what > toolbar buttons and menu options are used the most, so programmers can > make those one's buttons. So you just mean collecting data on frequency of use, to be sent to programmers to help them decide on later programs? Or would the program itself decide which buttons to make available? (I hate the latter.) > * Develop some technogical way to force programmers writing progs for > InterfaceWM to make the toolbar bleed into the top edge of the screen. It would be impossible to make all "toolbars" go up there, without modifying Qt, gtk+, fltk, GNUstep, etc. On the other hand, GNUstep doesn't have a generic toolbar widget yet, so maybe when one *is* implemented it could be like that. But it would still only affect GNUstep apps. > People who put the toolbar exactly 1 pixel from the top of the screen -- > so that it's safely useless in Fitss terms -- need to be clobbered with a > monitor. Or offset a few pixels from the left or right (hear that, Apple? You too, KDE!) > * The dock would bleed into the left hand side of the screen. It would > always be obscureable by default. That D you see at the bottom left hand > side of the screen would be a trigger (which would be the pixel at the far > lower left corner of the screen) that would bring the dock to the > foreground temporarily. It would stay on the foreground until you launched > and application or clicked on another window. The dock trigger is on the > 5th most clickable pixel on the screen. Sounds pretty good. Is the trigger the 5th most clickable (and not one of the other top 5) for any particular reason? > * Also in regards to the dock, since the pixels towards the upper left > corner of the screen are increasingly easier to click for RH-people, the > more often used progs should be on the upper portion of the dock. I like to arrange my own dock, thanks. (But it would be neat as an option.) > * Root window trigger at far upper left corner of screen. This is the 2nd > most clickable pixel on the screen. I'm not sure about this one. Obviously, you would need some way to get at the huge pie menu. However, the main idea of a pie menu is that it starts with your cursor right in the center, so that it's close to everything (correct me if I'm wrong). If the trigger for the root window is in the upper left, you essentially make it a pie menu that opens with the cursor extremely far away from all but one or two of the entries! > * Window list trigger at far upper right corner of screen. This is the 3rd > most clickable pixel on the screen. Sounds pretty good. > * All apps would share a common scrollbar, which would bleed into the far > right hand side of the screen. The huge buttons you see are there for a > reason -- larger buttons are easier to click on. True, you'd give up a > little bit of control in scrolling through manually, but so what? Most > people never use that anyways. I actually kind of like this idea. But I don't understand what you meant by "you'd give up a little bit of control in scrolling through manually." > * Allow for pop-up folders and menus to be stuck to the bottom of the > screen, and fly up when clicked on. (no animation). Explain what you mean by folders... would you be able to open a directory in the file manager by clicking on something down there? Or would it pop up a menu listing the files in the directory, going away once you clicked on a file? Also, would the menus be up to the user, or hard-coded? > * Any animations for opening, closing, minimizing, etc, should be kept to > a simple two dotted lines. Two dotted lines? More explanation is necessary. > * For submenu navigation -- we need a V-buffer space, so the submenu > remains open so long as the person is moving 2 pixels over for every pixel > down or up. This way, people don't have to navigate a narrow rift when > navigating submenus. I understand what you mean about the narrow rift -- I hate that! But I need a little more explanation of "V-buffer space." > Furthermore, dotted lines should display the > calculated critical path as the user moves the mouse forward. May want to > have hyperbolic V-buffer space: after all, as the user gets closer and > closer to the submenu, it is more and more likely that she wants to go > into it. More explanation is needed here too. > * It's about time we got the ability to automatically arrange windows. I > don't like manually sizing all my windows. Provide options for cascade, > tile vertically, tile horizontally, and other possible arrangements of > windows. I've always wanted to try Andrew ;) But seriously, I would like to have a variety of window placement options, both manual and automatic. > * Marry function to appearance. OSX and many WM themes are outrageous > examples of how function has been completely divorced from function. > Things that are draggable should appear draggable, and have a > high-resistence appearance. I understand the sentiment, but how does one make something look draggable? What does "high-resistence" look like? (And shouldn't something draggable have *low* resistence? :) ) > Things that are clickable should appear > clickable, and be inversely topological to our hands or fingers. Meaning they should look concave? > Things > that aren't clickable shouldn't appear clickable. > > Welp, those are my ideas. It's good to hear interesting ideas that depart a little from the stale norm. -- Furrfu! r a k k o at c h a r t e r dot n e t |
From: Chad H. <ceh...@ma...> - 2003-06-04 05:31:05
|
As you may know I am making a Dock.app for gnustep. It's a bit of a hybrid between the next stle and the OS X style of dock. How is it like next? It has tiles and is on the right edge of the screen. How is it like OS X? It is centered on the right edge and grows as things are added to it. It also shrinks to take in more icons. The plan is also to automatically "swallow" all App Tiles. I would alos like to put miniwindows in it as well Anyhow, I'm gonna need some interaction with interfacewm. For example, I'm gonna need to be able to know when windows are to be minimized as well as other information. I would like to keep all X11 specific stuff out of GSDock.app. Soo... I would need interfacewm to tell me, (via NSDistributedNotificationCenter?) that a window is to minimized along with: 1. An NSImage of the windows contents, preferebly smoothly scaled to no larger than 64x64. 2. A non X11 way of identifying the window. 3. The tile of the window 4. The pid of the application which owns the window (maybe not necc) 5. Probably a few more things. Anyhow, this would make interfacewm a bit easier to develop since all it would have to do is hide the window and pump out a notification. Likewise, when a window is to be unminimized, i would just tell interfacewm to display it. Are you guys interested in working together on this? Thanks! Chad |
From: Chad H. <ceh...@ma...> - 2003-06-04 05:46:07
|
#3 should say the "Title" of the window, not the "Tile" hehe Chad Chad Hardin wrote: > As you may know I am making a Dock.app for gnustep. > > It's a bit of a hybrid between the next stle and the OS X style of dock. > > How is it like next? It has tiles and is on the right edge of the > screen. > How is it like OS X? It is centered on the right edge and grows as > things are added to it. It also shrinks to take in more icons. The > plan is also to automatically "swallow" all App Tiles. I would alos > like to put miniwindows in it as well > > Anyhow, I'm gonna need some interaction with interfacewm. For > example, I'm gonna need to be able to know when windows are to be > minimized as well as other information. > > I would like to keep all X11 specific stuff out of GSDock.app. Soo... > I would need interfacewm to tell me, (via > NSDistributedNotificationCenter?) that a window is to minimized along > with: > > 1. An NSImage of the windows contents, preferebly smoothly scaled to > no larger than 64x64. > 2. A non X11 way of identifying the window. > 3. The tile of the window > 4. The pid of the application which owns the window (maybe not necc) > 5. Probably a few more things. > > Anyhow, this would make interfacewm a bit easier to develop since all > it would have to do is hide the window and pump out a notification. > Likewise, when a window is to be unminimized, i would just tell > interfacewm to display it. > > Are you guys interested in working together on this? > > Thanks! > > Chad > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Simplygnustep-discuss mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss |
From: Chris B. V. <ch...@we...> - 2003-06-04 16:11:38
|
On Wed, 04 Jun 2003 15:15:24 -0700 Chad Hardin <ceh...@ma...> wrote: [...] > Anyhow, this would make interfacewm a bit easier to develop since all > it would have to do is hide the window and pump out a notification. [...] I've been playing with GNUstep's application icons and several window managers (both kinds, that is, those that use/display icons and those that don't) to see how both interact. Bottom line is: GNUstep doesn't give a shit whether the window manager can/wants to display application icons or not. It will pop them on your screen anyway. There are two (why two I have no idea) NSGlobalDomain settings that are supposed to turn app icons off (at least that's what the docu implies), GSAppOwnsMiniwindow and UseWindowMakerIcons. I couldn't figure out whether those two are mutual exclusive or need both be set but I tried every possible setting I could think of and the result were always the same -- GNUstep seems to ignore them. -- Chris |
From: Chad H. <ceh...@ma...> - 2003-06-04 18:31:10
|
Hmm, I didn't know this...Interesting... Maybe you should bring this up on the gunstep mailing lists? Wait a minute, I remember someone putting a post something along these lines to gnuste-discuss last week I think, was that you? Chad Chris B. Vetter wrote: >On Wed, 04 Jun 2003 15:15:24 -0700 >Chad Hardin <ceh...@ma...> wrote: >[...] > > >>Anyhow, this would make interfacewm a bit easier to develop since all >>it would have to do is hide the window and pump out a notification. >> >> >[...] > >I've been playing with GNUstep's application icons and several window >managers (both kinds, that is, those that use/display icons and those >that don't) to see how both interact. > >Bottom line is: GNUstep doesn't give a shit whether the window manager >can/wants to display application icons or not. It will pop them on your >screen anyway. > >There are two (why two I have no idea) NSGlobalDomain settings that >are supposed to turn app icons off (at least that's what the docu >implies), GSAppOwnsMiniwindow and UseWindowMakerIcons. I couldn't figure >out whether those two are mutual exclusive or need both be set but I >tried every possible setting I could think of and the result were always >the same -- GNUstep seems to ignore them. > > > |
From: Chris B. V. <ch...@we...> - 2003-06-04 18:35:25
|
On Thu, 05 Jun 2003 04:14:58 -0700 Chad Hardin <ceh...@ma...> wrote: > Hmm, I didn't know this...Interesting... > Maybe you should bring this up on the gunstep mailing lists? Wait a > minute, I remember someone putting a post something along these lines > to gnuste-discuss last week I think, was that you? No, I did post something about it a good year ago when I checked back then. I just checked again last weekend and found that nothing changed. -- Chris |