Hi Christopher, Here is my real reply… :-)
Le 1 févr. 2011 à 00:43, Christopher Armstrong a écrit : > On Mon, 31 Jan 2011 15:03 +0100, "Quentin Mathé" <[email protected]> > wrote: >> 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. > > Yes I agree with this too. I don't know why I didn't put this down in > the first place, although I was trying to keep this bit simple. I should > probably expand the definition to something like. > > A project is the repository for a set of related objects, > including views, contacts, documents, discussions, music, > video, lists and other pieces. Sounds much better, except a project isn't really a repository (if we consider a repository as something that sandboxes/encloses the objects it contains or implement a persistency model). A project doesn't version the objects it appears to contain. These objects (contact, document etc.) are in charge of versioning themselves and don't belong to the project, although the project references them. Any core object can be shared between multiple projects. As a side note and from a usability perspective, whether or not core objects can be opened in several projects at the same time is still an open question. I'm tempted to say having a core object opened in multiple projects is just fine. For example, editing the same contact in two projects running in parallel makes totally sense (e.g. suppose you are working with this person on two separate work projects). It might be less desirable to support this ability on a compound document… but given CoreObject will push the changes back to all existing instances in memory, to keep things consistent in regard to the contact example I just gave, allowing the user to open a compound document in distinct projects seems reasonable. >> - "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. > > I was referring to the idea of the project overlay given on the website > in the walkthrough with screenshots. Ah ok, I forgot about this document. Based on Jesse's description, the Project Overlay is a specialized Object Manager for Projects. The description I'm referring to is: "The Project Overlay shows all the non-active documents within the Project, and also includes a bottom bar." You could imagine to replace the UI described above with something that gives me a better overview of the project (contacts, bookmarks, recent work in this project, todo etc.) though. In the long run, perhaps this UI should be customizable to let he user decides what content is visible or summarized about the project. Just make things clearer, here are some extra notes: An Overlay (the bottom bar + the semi-transparent area above which presents various elements) is equal to a full-screen Object Manager minus its menu bar. An Object Manager not in full-screen mode and with a menu bar would look like this: http://jesseross.com/clients/etoile/ui/concepts/03/workspace_100.jpg (in this screenshot, it's generic Object Manager that is presented) But ultimately both uses the same code (the Overlay presentation might want to use a custom UI though). From an implementation perspective, to get an Overlay you could just launch an Object Manager app bundle with a custom default stating run it as an Overlay. In some cases, we might decide that an Object Manager will always be run in Overlay mode and as such doesn't need a window-based UI and a menu bar. e.g. the Shelf Overlay. Each Overlay probably runs in its own process unlike a normal Object Manager instance which present multiples windows. Not sure about that… but just to bring the point into the discussion. > I guess if there was a generic > object manager, which would probably just be a service or a view > available from the project manager service, it would be the Object > Manager set to show just the views in the project in their visual > representation. By generic Object Manager, I mean something that lets you browse all the core objects organized into groups/tags with a file manager-like UI as visible in http://jesseross.com/clients/etoile/ui/concepts/03/workspace_100.jpg What you seem to describe by "Object Manager set to show just the views in the project in their visual representation" is rather a specialized Object Manager similar to Exposé on Mac OS X. Or am I missing something? > I've sort of had this discussion with David and thought a bit about this > myself. I think its important we separate the ideas, so that views are a > type of object, but they are also just one organisation of the visual > layout of an object. For example, you may have a contact which is show > in many views, so there will be a contact object and the many view > objects. Makes sense. > To the user, its probably best to show the views in the > overlay, because thats what they'll remember when they last opened the > contact in those views, but just show a generic object representation in > the Object Manager. Yes, especially important if the object is opened in several projects at the same time. > Its probably not even a good idea to mix the view > objects and the more model objects in the Object Manager, otherwise a > user won't logically understand the difference between them or even be > able to distinguish them. Yes, that's very important. Well, we can decide to persist each view geometry as a core object, but this should remain an implementation detail and we should keep these core objects hidden e.g. when the user browses the entire core object graph. > But expanding on this again, objects may not sort of be tied to just one > project. I would certainly want my contacts (for example) to be > available in many projects. I guess its the idea of a workspace, that > has projects and all my "objects" (whatever that means), and I can link > in or bring into my projects various objects and share them between > projects. Yes, if you cannot share objects, the project concept is kinda useless imo. That's related to what I wrote at the beginning, where I outlined that a project is not a repository. > How a person is to distinguish between an object they share > between projects and one they "cloned" into another project I don't > know. Because a project isn't expected to contain or own core objects, you can share core objects freely without copying/cloning them. However that doesn't prevent to make a copy or a start a new branch for a particular core object… and only uses this copy or branch when working within a precise project. The branch case would need some special support to track the core objects which have branches explicitly associated with one or more projects. In reaction to 'Open Document', the editing would restart in the right branch. This branching use case might prove to be not so useful in the end… Basically I think we should support branching as a advanced user ability, but not bother too much with integrating branching deeply into the UI (as the project-based branch example I gave). My opinion is the branch concept is hard to grasp, and managing branches is hard conceptually too, even if we eliminate all the usability issues that plague current revision control system. > That starts to get into the territory where you could fork the > common base of a project in the same way one branches a repository tree, > which seems too complicated to begin with for a first cut of the > architecture and difficult to support. If objects can be freely shared as explained previously, this kind of convoluted scenarious shouldn't be needed, although CoreObject design doesn't prevent to support them. >> 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". >> > Yes I guess this could work. A project could dictate a set of document > templates, or even the default layout of a new document of a particular > type created within that project. See my notes below. ok > 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. > > Actually my idea behind templates and the arrangement of auxilliary > windows for a document was to store the preferences for each document, > not at the project level. I guess we could have three to four levels of > customisation of auxilliary windows (in decreasing order of > prioritisation) > > Document Level > > Document Template Level > > Project Level > > Project Template Level Sounds good. > Personally, I think the first two are good enough. A document template > is just a copy of a document, and if a document includes the layout of > auxilliary windows, then you logically just customise the display/layout > of those windows after creating a document (possibly even using the new > customisation for a new template). I don't have a counter-example right now, so I agree :-) I'll try to think about various customization use cases to see whether Document Template preferences are enough or not. Some project preferences would be good though e.g. sound volume, desktop background. If we can support: - custom UI per project with template-based preferences - system-wide preferences per project then having an extra NSUserDefaults domain to allow customizing app preferences per project is probably not needed. > This would expand the definition of a view to: > > A view is the visual representation of an object in the project. Yes, that would be more accurate I think. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
