On Tue, 6 Apr 2004, Gil Freund wrote:[snip]
My point was that they were. Both CUPS and RH have a cash flow.CUPS (the original example given) is an foss project from a company that make a parallel commercial product. It has a licensing cash flow and therefor has money not related only to "support and service". The same is true of Mozilla, Openoffice.org and opengroupware, to name just a few. The CUPS example is excellent in the sense of how an _implementation_ of a foss product has failed. 1. The project maintainer implemented a security feature without referencing it in the documentation. 2. The distro maintainer entered a a package into the distro without due consideration of how the package operated in the distro environment.
Both points don't contradict the general statement - if they were paid (in money or otherwise) for their jobs, they'd have time to find and fix those problems.
It doesn't. I thought it was a was a very valid point. I do think it refutes the claim that the UI *requires* a commercial licensing structure.
1. How would people, who want to be GUI designers, get trained in the art of GUI design?
Read Eduard Tufte's books on design. It's not UI, but on how to present information, and check out Orelly's "Annoyance" series.
s/get trained/get experience/ - mea culpa.
2. Widely-used Free Software is an unbeatable way to advertise one's GUI design expertise.
I would think the same holds true for advertising your coding skills.
How does this refute my points?
3. Reduction of effort and cost of building excellent GUI by reusing composite controls, design patterns, templates (like wizards) and prior art.
True, but they this contradicts what you state in section 5. A commercial (G)UI would prohibit that.
Not necessarily. LGPLed widget sets would allow building commercial GUIs from them. Or even GPLed ones with special exception for allowing use for constructing proprietary GUIs. Where is the contradiction with my suggestion that special licensing models might help?
There is a huge gap between _LGPL_ and _commercial_ licensing. LGPL is indeed (in my opinion) a reasonable path to advocate.
I think KDE and Gnome try to achieve this.
4. Super-GUIs, which over time learn what and how users actually perform their tasks; and then automatically construct special-purpose wizards to help the users perform those tasks with minimum effort.The learning is not necessarily confined to a single user/installation.
Are you talking about AI or machine learnability? If so, this is science fiction.
I don't envision this as being prohibitively difficult.
Software, which captures user's actions (keypresses and mouse actions - after being interpreted by the target application) for a long time and finds repeated patterns - might construct wizards for those repeated patterns. The big stumbling block is to make such software interoperate with the wide variety of GUI applications out there.
The wizards won't initially be pretty but the user might later tweak the GUI (if the wizards are compatible with GUI design tools like glade) to fit better the task on hand.
I think this clouds the GUI / usability issue. They are not the same. Learning users preferences (such as baesian spam filtering) is not necessarily a UI issue. Learning usage habit should start long before the UI is even drafted.
One of the problem I see facing users is the the users often mix usability, functionality and UI. If you turn to most users in the correct corporate market and ask them to describe the functionality they require from their PIM (Personal Information Manager) you will get a fairly accurate product brochure for Outlook. The outcome is, not surprisingly, Evolution.
Add an AI which learns the users work habits on the same GUI and you will end up with same application with a slightly different menu structure. You *will not* find the next Ecco, PackRat or Act.
5. Licensing models (like LGPL), which allow an application to be split into Free part with command line interface, and Proprietary part, which implements top-notch GUI.
Bad idea. Consider the Bynari mail server. This is a collection of foss products (OpenLDAP, Postfix, Cyrus IMAP and other) collected and integrated with a cool management GUI and and outlook connector. This is a very robust exchange replacement. In order for this to work, you are forced to use the versions of the foss applications bynari can interact with. This means that you end up for a propriety solution, that limitsyour options.
Not exactly. You have (or supposed to have) access to the interface between the GUI and the Free software modules. So you can implement your better features as long as they work with the same interface. So you still get some benefit from the Free Software model.
While true. I think this overlooks the "Aunt Tillie" argument (for A.T. read also MCSE....): If I want to tweak that application(s) then the UI is secondary. Consider the CUPS scene once more. The same goals could have been achieved using lpadmin or editing the cups.conf files. The A.T. argument is that the user should be able to achieve complete functionality using the GUI.
--- Omer My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
