Maqetta workspace and Project
Up until now, Maqetta used a single workspace for all of the user content. As we go forward and integrate with other development tools, workspaces become essential.
Most tool have a project concept represented by a folder containing a collection of resource and settings. Projects can typically be linked or a dependancy of another project. Project settings typically cascade down from a high level workspace setting, but can be tweaked at the project level.
Maqetta has tried to avoid the typical 'project' notion in the UI due to its geeky nature. The rest of this section discusses the diffferent approaches that achieve interopability with other utilities which use projects. One approach goes the completely traditional route, while the other hides most of the project UI from the user.
This approach is the 'do as everyone else' approach. We would simply show projects as folders in the UI, and allow the user to manipulate settings on the project like they do through Eclipse. Projects would be very succinct, visible collections of resources. The UI would evolve very similar to Eclipse.
Users would see an empty workspace (or a 'create a new project!' wizard) when they first log in. They could then create a new project which would show up as a folder in the File Explorer view. Default project files would be copied in, and the user could begin mocking up pages in the new project. The user could right click on the folder and set project settings, import, export etc..
Projects on the file system will be identical to projects in Prop #1, however the UI will be very project light. At the server/file system level, the user will have a root folder (the workspace) and sub folders. Each sub folder is a project. The project can have its own settings or it can inherit the global settings from the workspace.
In the UI, the users workspace will remain how it is today. They will only see the current project that they are working on. However, above the File Explorer view will be a dropdown with all the users projects-- and the currently active one highlighed. To the right of the dropdwon will be "Open" "New" "Delete" and other project specific options. Each project will look like the users whole workspace, and multiple projects can be edited in multiple browser windows-- one window per project. Interconnections between projects will still be available in the deep UI, but the user will be spared the resource tree view, and the confusion/clutter around managing many projects at once.
This approach will also leverage the tab features of almost all browsers.
We could offer two different views for the Files palette (or maybe renamed to Navigator or Explorer). For initial users, they would see a nice, simple UI showing a single project view, just as we have today. But there would be an advanced mode where the palette changes into a full hierarchy of workspaces and projects, where the current project would be a piece of a much larger tree.
The Orion project has some interesting features in the whole "navigator" area that we might want to adopt in Maqetta, including sharing the UI control(s) for showing the files, projects and workspaces.
Orion has a notion of a "File Service" which represents (at least conceptually) a "managed workspace", where specific file service plugins put a layer of intelligence over what otherwise would be a dumb set of folders and files. There is a File Service for Git, which adds some Git smarts to a dumb workspace (ie, folders and files), and there is a File Service for SFTP, which allows Orion to read/write into a remote workspace using the SFTP protocol.
If we are lucky and clever, maybe we can map the Eclipse notion of a "workspace" to the Orion notion of a File Service, where one strategy is that there is an "Eclipse Workspace File Service" whose "layer of intelligence" includes some understanding of Eclipse project data???? But it seems like we would need File Services to support both Orion's current repository options (Git vs SFTP vs whatever) and orthogonally also have the option to understand Eclipse notions such as projects.
In Orion's navigator UI, each file service represents a highest-level container that holds its own subtree of files and folders. Orion doesn't allow drag/drop moving of files across file services. If Maqetta shares navigator UI with Orion, then our files/explorer/navigator palette probably would have to also show File Service roots as highest-level containers within the palette. If we use an approach similar to Prop 3 above, then we can offer two views. The default view would be a single-project view that looks just like the current Maqetta Files palette (Sample1.html, Sample2.html, etc). The alternate view of the files/explorer/navigator palette would show the user's full workspace, with File Service roots at the highest level, then project folders underneath that, and then random folders and files (including libs/ and themes/) under that.