On 2002.02.10 13:33 Eric Christianson wrote: > If PicoGUI is targeting embedded devices, the majority of > them use smaller screens. I think UI's that try to target this > area could be decent "role models" for a UI. There are several > examples of these that exist, Microsoft (CE/PocketPC), Palm, > and symbian are environments design for smaller embedded > devices. We can all name things we like or dislike about each > environment but they mostly contain a common theme. When you > are dealing with small real estate (160x160 was given as an > example) the task you are currently doing should be given the > most screen real estate. Take Palm for instance. There is no > "menu bar", scroll bars are limited, and they have some custom > hard keys to navigate. When you are running an app, it runs > full-screen. This is true of the PocketPC and Symbian environments > as well, because with countless dollars spent on usability > research, the majority of the population gravites towards being > able to use and comprehend this model.
I think you're missing the point of PicoGUI- to create the best GUI for embedded systems regardless of other GUIs' "standards". This goes for application arrangement too. It's true that the average handheld user will want to run one app at a time fullscreen. _BUT_ this doesn't mean we should force the user into only running one app. This is one thing i hated about PalmOS. Maybe normal users are fine with only running one app. They can ignore most of PicoGUI's functionality and always keep only one frame on the screen. But the power users will love the extra flexibility. Remember that the user should decide how to use the interface, not the application programmer or device manufacturer. > > So I am in favor of a UI that allows being able to focus single > applications in a fullscreen environment. The current UI allows > for that, although it could be made more straight forward. I > believe the tiling that currently occurs is difficult to navigate, > as suggested by Phil, but at the same time I don't think that > use-model is going to be a common occurence. In general, tiling is > useful (IMHO) where you have multiple pieces of information that you > want to give about one active screen. Or put another way, you might > want to display a clock, current weather, and a stock ticker, while > having your "current application" in the foreground. For the most > part this will be controlled by the programmer. It should not be controlled by the programmer. I know that is common in existing PDA environments, but that IMHO is one of the PDA's larges t limitations on flexibility. For example, what if the user wants to play music while editing a database. Admittedly current PDAs arent' great at playing music, but this is just the first example i could think about targeting the mainstream PDA audience. Current PDA environments force you to run the music player app, have it play music in the background, then switch to the database. There's no way to keep a little info on the music on your screen. In PicoGUI, just have the music player run in a toolbar. Another common example- what if the user wants to do some quick calculations while writing a memo. I did this occasionally on my PalmOS device. You had to run the calculator, _remember_ the result while switching to the memo pad, then enter it in. Very inefficient. You should just be able to run the calculator and memo pad side by side. > > Of the usable solutions that exist, obviously Palm's model has been > the most successful in the handheld PDA market. It represents a good > model for hand held devices. Qt has made a similar UI on top of > Linux in an attempt to enter that market share. I think PicoGUI > has to decide if in fact it's a PDA-style GUI, or smaller embedded > device GUI? The reason for this, is because you can't optimize for > all solutions. (Look at Windows for an example of how it doesn't > scale well across devices.) If in fact PicoGUI is trying to be > everything-to-everyone, it won't make it mainstream. Qt took a > narrow approach, and one could argue it's been one of the most > successful linux gui's to date in embedded systems. PicoGUI started out as a PDA environment. But, it turned out to be useful for smaller embedded devices, like cellphones, clocks, etc. These kind of devices won't run the PicoGUI Launcher, or a PIM app, they will run one specialized app that wants the entire screen. Currently this is done by turning off or heavily modifying PicoGUI's panel/panelbar system. With the new 'frames' system, it should be just as easy if not easier. With only one frame on the screen, the current app will always occupy it. I think that basing the design of any application on the design of what's currently selling well is fundamentally wrong. It leads to infinite copycat systems with no real development. I've already said that PicoGUI aims to be different. Practically, this should mean taking the best parts of what's available and adding our own features into the mix. PicoGUI borrows it's client-server architecture from X, it's widgets are a bit Tk-like. The theme system is completely new. Windows doesn't scale well across devices because its design is wrong to begin with. In Windows, you can either spend all your time moving and resizing windows, or use one application at a time, fullscreen. A good point to be made is that an interface designed for handhelds is usually a more efficient interface for any device. > > I think by Micah putting a stake in the ground there will not > be "overlapping" windows, it's not designed for a web-tablet or > similar device. I think this is a great choice, as there are numerous > gui's that satisfy that space already. (NanoX, tiny X, Qt, etc.) I fail to see how a wab-tablet device would require overlapping windows. It is like a PDA, but with a larger display. This becomes a problem for traditional PDA environments because they still assume the user only wants one application fullscreen. Since PicoGUI does not make this assumption, it should scale well between environents that work best with multiple apps and environments that work best with single apps. > > Whatever GUI architecture that is decided on for the "default" > environment, currently represented by the pgl-stuff, I suspect > that many devices won't fall under that usage model. Take for > instance digital cameras, cell phones, camcorders, etc. None of > these even have a pointing device, and they represent a huge portion > of the embedded space. I just hope whatever solution is picked > as sort of the "general use" model, that the gui can be tailored > to fit almost any situation in the small embedded device space. > (Ranging from PDA's down to watches and perhaps smaller.) I believe > this is currently supported by the current architecture as well. > (You can have no-height panel bars, you can hide/show apps by > changing the height of windows, and the best part of all, this > can be decided at run time throug the theme support provided.) These smaller devices should be fine with just turning off whatever window management scheme we come up with. > > After all this is said, the most powerful aspect of PicoGUI is > it's theme support. This continues to be one of it's best > strengths in the embedded gui space. Whatever architecture is > decided upon should continue to put the themeabilty of the > gui as it's highest priority. I think the current design does > this as well. PicoGUI has been going for close to two years > no (from the inception) and one of the most important aspects > I see it needs to work on is moving towards stability. In the > embedded environment one can't readily download the new version. > :) Yes, the theme support has been one of the coolest things about PicoGUI. And this isn't because we copied it from the leading PDA environment, it's because it's completely new. And about the stability.. that's why we could use more coders for this stuff, since i've had my hands full fixing bugs and hacking at pgserver recently :) > > Anyways.. just throwing in my two cents about general directions > without giving any specifics. I like Palm's model, as it lends > itself to many types of devices. I like the ability to hide > bars, but to have them there if required. I also don't see a > problem with PicoGUI's actual UI design in it's current form. > I think what is more being talked about is the "pgl-environment" > in it's current form. This new window layout scheme will have nothing to do with PGL, it will replace the current panel and panelbar widgets. > > Eric > > > > _______________________________________________ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel > _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
