On 22 May 2005, at 17:44, Jesse Ross wrote:
What about 'Content'? We are already using the term Object in a programming context -- it would be good if we didn't have to always differentiate between the two when talking to others or explaining things.
Not sure about `Content', because it seems rather too abstract (also, it's hard to talk about something as `a content'). Object is definitely not the right word, but I haven't yet found anything much better. I picked object because users from a Windows background will be familiar with the idea of embedded objects via OLE / ActiveX, which are superficially similar concepts. I suggested blobs in the other email, perhaps content blobs would be a good term?
What do we call Components that do present a UI then? If I said Filter, you would know exactly what I meant, but if I said Component, you wouldn't know whether there was a UI or not.
<snip>
We should probably give the ? a name so that it can be differentiated from Filter in a concrete way. Ideas: Palette, Module.
How about tool? Module seems not to convey any information about use, and palette seems as though it ought to refer to a collection of tools.
If we were looking at the Project-based Desktop or Narcoleptic Electron's proposal, Widgets would be things that existed outside of any projects, perhaps in a shelf like space -- like Dashboard. I just got Alex's email and he proposes Applet. I think that might be a better term. Additional ideas: Utility, Desktool.
I think widgets should be able to exist anywhere on screen (not confined to a shelf), but they should not be as tightly coupled to projects as objects (content blogs?) - this may not mean anything from a system perspective, but the expectation should be that these are stored on a shelf, and put in a project while they are in use, rather than stored in a project and put on a shelf to move them around.
One category I completely forgot - games - will probably be widgets / applets / docklets / utilities / desktools, and so it is probably a good idea if the name reflects this.
There is some validity to this (things that work different should appear different), but I would personally rather design a new theme than use the GNUstep one. Something that was a bit more integrated into Nesedah (just as modern), but maybe using a different color. Or, maybe not...
Non-GNUstep applications will use the theme implemented by their toolkit, so it would make sense for GNUstep apps to use their default theme. Implementing something new would make them look as if they were designed to fit into the new system, which is exactly the opposite of the impression we wish to convey - Applications are legacy tools, and should only be used as a last resort.
Since we are the designers of this system, we can say what can happen and what can not. As such, maybe we don't want legacy applications on the system at all, to make things easier on the user. Imagine you get used to making a new Document via the Workspace, then you make a new Document to edit images and realize, "Oh, wait, I can't do that, I need to start Gimp (or whatever) to do that". The user has to switch contexts in their mind and backpedal, and has to remember what can be made via Workspace and what requires an app. It seems like a lot of extra work for the user. I would use use legacy apps maybe as a temporary solution, but by a 1.0 launch, all support for them should be gone, having been replaced by Components.
If we make this constraint, then we will never get to 1.0. I would think that we should aim to implement 80-90% of what people need (or 100% of what 80-90% of people need) with Components, but still provide them with a mechanism for running legacy applications for the 10-20% we haven't covered. Think back to the OS X launch - how important it was then that it ran OS 9 applications, and how unimportant it is now (except for playing old games, of course).
