Bugzilla – Full Text Bug Listing
| Summary: | [client] Creating new file and folder awkward in nav table view | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bokowski, john.arthorne, johnjbarton, paul.beusterien, Szymon.Brandys |
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 334189 | ||
| Bug Blocks: | |||
|
Description
Susan McCourt
The current instructions are something like:
Log in and click the "Link Folder" or "Link Project" button on the toolbar.
Type in a name for the link, and in the Server path: field, enter the path to the folder you want to link to (it must be a subdirectory of one of the paths you supplied in Step 2). Then click OK.
I find this confusing because the input field label is "Folder Name". As a new user I have no idea what you mean by "folder". The next line is "Server path" then a check box Create if doesn't exist. I just don't know what to do with these fields.
I think the UI would be much clearer if you don't use dialog boxes at all. Instead, put [new] right after Name in the navigate-table page. Or have a blank entry at the end of the Name column with gray "add link to filesystem". Then add a Path column to the UI holding the value of the server path. This way the user knows directly what the UI operation will do, to the extent they understand the naviagate-table.
Rather than only a text input for the file system path, let the user browse to a directory from the paths available. Its just another tree viewer I guess.
too many fires for M5, this will have to wait for M6. Probably makes more sense because we'll be reorging things into commands and cleaning up more than just this problem. As part of the progress on bug 334189, the new file/new folder/import commands are now available in both the breadcrumb and as commands alongside individual items. This is a big step for the command service, just a small step as far as improving the UI. What needs to happen: - the file manipulation commands alongside the items need to be grouped in a button menu in the actions column. I'd like to see new file, new folder, import, and delete move to the menu, leaving "make favorite" and "download" as the icons remaining. - As John suggests, popping up a dialog to simply enter a name is a bit overkill. If we could insert an edit box somehow in the menu or in the dom nearby, we could avoid a dialog box. Will have to play with this once I get menus rendering. (In reply to comment #3) > What needs to happen: > > - the file manipulation commands alongside the items need to be grouped in a > button menu in the actions column. I'd like to see new file, new folder, > import, and delete move to the menu, leaving "make favorite" and "download" as > the icons remaining. done. > - As John suggests, popping up a dialog to simply enter a name is a bit > overkill. If we could insert an edit box somehow in the menu or in the dom > nearby, we could avoid a dialog box. Will have to play with this once I get > menus rendering. this part will have to wait for M7 A really big improvement would be a [browse] button to open the native filepicker when filling the filename field. I found the whole concept of being forced to create an Orion folder to manage my project confusing. What's the reason for Orion folders? Why not make them implicit and just allow users to choose their content - local directory, git project, or whatever? (In reply to comment #5) > A really big improvement would be a [browse] button to open the native > filepicker when filling the filename field. I'm not sure I understand this. If we are creating a new file (not linking to an existing one)...why would you want to link to the local file system?? (In reply to comment #6) > I found the whole concept of being forced to create an Orion folder to manage > my project confusing. What's the reason for Orion folders? Why not make them > implicit and just allow users to choose their content - local directory, git > project, or whatever? For M8, we are talking about a landing page that would generate the folders, etc. So that you wouldn't have to know about folders to get started. But once you are inside some project, and need a new folder for your own organizational purposes, you could still choose "new folder" As for this bug, I would like to get rid of the new file/new folder heavyweight dialog and just have a div that pops out off the menu/button itself. See bug 342739 Paul, I cc'ed you on the landing page bug (bug 343290). Welcome all comments/ideas! (In reply to comment #7) > (In reply to comment #5) > > A really big improvement would be a [browse] button to open the native > > filepicker when filling the filename field. > > I'm not sure I understand this. If we are creating a new file (not linking to > an existing one)...why would you want to link to the local file system?? I think I misunderstood this bug. I was commenting on the linking popup dialog. For 0.2M8, bug 342739 requests a general mechanism for popping out of a menu to collect info. I want to address this as part of that. Fixed. There's two contexts where you can create a new file/folder. From the nav context menus, we now popup an edit box in-line in the navigator, a new row underneath the parent. When the user finishes entering the name, we then refresh the item (and expand it if it wasn't expanded before). From the toolbar (which creates the object at the nav root). For now, I just popup an edit box in-line in the toolbar. One could argue that the edit box would be better if it popped up in the navigator in a top blank row, but I wasn't sure if the eye would catch that since you are looking up at the left hand side and might not notice an edit box opening up below. We'll see how this plays and we can do something different if folks find this weird. |