Hi Christopher, Le 30 janv. 2011 à 13:25, Christopher Armstrong a écrit :
> Hi all > > I wanted to promote discussion on the architecture of Project Manager and how > it interacts with the user and the operating system. I've put together some > notes about how I think it should work (i.e. you may have better ideas or > could elaborate on mine further). I intend to use these to experiment with > such ideas so I can get a feel for how well they give a good user experience. > > The notes are stored in SVN under trunk/Etoile/Documentation/ProjectManager > in TeX format. > > I've generated a PDF of these notes stored here: > > http://etoileos.com/uploads/documents/ProjectManagerNotes.pdf It's a great idea to write all that down :-) I agree with most points described in these notes, so I just have some small comments. On p. 3 - "Project A container for holding a set of views. The project remembers the position and stacking order of views on the screen." I'd say a project is much more than that… Projects are expected to track the various "elements" involved in a project (people, documents, discussions etc.). We'll probably have a COProject class as a specialized core object group to describe all that. Initially a simple COGroup to which all these elements are members of could be good enough. - "Project Overlay A window that is temporarily displayed over the top of the workspace to allow the user the select a view to open." I'm not sure to understand what this is precisely. Would that be specialized Object Manager for projects in the same way than Mélodie is a specialized Object Manager for music? The way I was envisionning project management and opening was to use the generic Object Manager. Given that projects are core objects then they can browsed, organized and opened exactly as other core objects. That seems good enough to begin with, although a specialized Object Manager in some sort of window overlay might worth to explore. - "Service A service is a GNUstep application that displays the contents of documents in views on the screen. A service has one instance in the user’s workspace, but may be displaying multiple documents and views." This describes viewing/editing services well, but I see Étoilé Services as a generalization of the OpenStep service concept. Each service is bound to a name and one more data types. For example: 'spellchecker' bound to /path/to/a/spellchecker.bundle and public.text 'musicmanager' boun to /path/to/melodie.app and org.etoile-project.music-library The name would also have a contract which describes the inputs and ouputs the service must support and few other stuff probably. -- On p. 5 A minor remark… Creating and Opening projects would also be possible from the generic Object Manager, since it can be used to instantiate, organize and open any kind of objects. When you double-click a core object bound to a manager or editor service as explained above, then the specialized manager/editor is started rather than opening/visiting it in the generic Object Manager. As a reverse example… if the Mélodie association with org.etoile-project.music-library was removed, double-clicking a music library would open it in the generic Object Manager. For Closing a project, I suggest to also add a menu entry. -- On p. 6 - "The user goes to the template chooser and selects a template to instantiate as a new document." Just a side note here… I'd love to have project templates too. This would come naturally if we have a COProject model class. In this way, we treat and manage "projects" as "documents" and the whole screen is really a "compound document". I think this makes things simpler and more consistent. At the UI level and in the user-oriented terminology we use, however we might not want to insist too much on stating that "projects" are "documents". -- The rest of the Project Manager Notes sounds good me. Minus the section 2.1.7 Open a view within the project, but that's related to the fact I'm not really sure what you mean by Project Overlay. -- What you don't discuss, but seems really important to me is to have per project defaults/preferences. With that, projects would be much more than persistent workspaces, they can be customized to better fit the project activities. For example… With an image editor, when I'm doing some web design, I don't use the same UI arrrangement than I'm going some photo editing. For an IDE, when I edit HTML or CSS, I don't want the UI to be the same than I edit Objective-C code. etc. What I usually do on Mac OS X is either: - I do nothing and I use a suboptimal UI arrangment (most common cases) - I manually rearrange the UI each time I change my current project kind To support, that there are two options: - running a service instance per project - supporting a new 'Project' default domain and on a project switch makes the running services (in the project we switched to) reloads their defaults The first option has various issues such as: - hard to move views or windows between running projects - repeated launch cost and process multiplication Hence option two seems to be the most reasonable one. I think we should be able to get the UI changed instantaneously… If reading the defaults from disk each time a project switch is too costly, we could cache them in memory (but I think NSUserDefaults already does it). Also we could hide some UI parts rather than close them, when they are not needed in the UI arrangement that goes with the current project. We could have services switching the components in use based on the current project too. For example, an IDE woud have some web related components loaded in a web dev project, but other components would be used in an ObjC programming project. In conclusion, we could have "project templates" such as Photo Editing, Web Dev, Print Design, Daily Use, Accounting etc. that provides various project kinds as a starting point. Each project template would have an optional set of project defaults bound to each service. Project defaults would override the defaults set in the NSUserDefaults 'Application' domain. General setting such as the UI theme could be changed per project too. To give an example, in a Photo Editing project, the entire UI could be switched to a gray-level theme (that limits how much the user color perception is alterated by the surrounding colors in the UI). Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
