[UX] two parallel structures for file management cause usability problems

[jdittrich]

What happens: Using brackets in an educational project for teaching web programming the division in "working files" and "current folder" (or "project" ) frequently (ca. 50% of all usability-related problems) causes confusion as it makes the application act inconsistently from the users perspective.

• Files from the current folder are opened from the current folder but other files are opened the working files list
• It confuses users that the preview from "folder"-files is live, but from working files its static

What should happen: Very conservative but less problematic would be:

• Every pages that is edited appears in the working files list.
• the current folder could be visually distinctive from the working files
• live preview should be possible for working files too.

[njx]

@jdittrich - thanks for the feedback - it's nice to hear about people using Brackets in educational contexts. I'm a bit confused by the bug report, though, because it should already be working the way you want, so there might be some other deeper problem going on.

The way it's supposed to work is:

1. If you just single-click on a file in the file tree, it shows the contents of the file but doesn't add it to the working files list.
2. If you then make a change to the file, it adds it to the working files list.
3. If you double-click on a file in the file tree, it adds it to the working files list immediately.

This model is the basically the same as how editors like Sublime or Espresso work, except that in Sublime there are tabs on open documents as well as the working files list in the sidebar.

Also, live preview should definitely be active in files that are in "working files", so if it's not, something's wrong. Could you post more specific steps to describe what's not working?

[jdittrich]

live preview should definitely be active in files that are in "working files", so if it's not, something's wrong. Could you post more specific steps to describe what's not working?

sure. Steps to reproduce (sprint: 35, Chromium 31.0.1650, Ubuntu 12.04) 1) Open some HTML-file which is not (at any level) in the current folder (the folder displayed below Working Files) 2) Click "Live Preview" Result: The file opened staticly rather than live (So it has file://… instead of http://127 .0 …)

For the causes of the rest of the problems I am unsure. I did not do any formal usability testing, so it's just inferred from students comments. If there is interest in that, I'd like to investigate that further, observe it closely and ask for expectations vs. actual behaviour.

[njx]

Ah, I see. The issue isn't that working files aren't live - it's that files outside the current root folder are not live. In general, the model is that you open the top-level folder containing all the files you want to work with (e.g. the root of your project). If you were to give students that guidance, do you think that would help? Or is there a reason why they typically need to edit files outside of the open folder?

[jdittrich]

If you were to give students that guidance, do you think that would help?

I mentioned several times, but I think it was buried under piles of other stuff they learned. I think it would be great if they would not need to remember this too. (I assume the current behaviour has some technical reasons – I'm exclusively describing it from the point of usability)

Or is there a reason why they typically need to edit files outside of the open folder?

As well, the students may have two folders in parallel e.g. like having a Folder with a "hello world"-example-page made by the tutors on the Desktop and their own page in another folder in their Documents-folder. They copy stuff from there between both and see what happens and make changes to both. (I 'll try to check the detailed workflow soon)

[njx]

Yes, we've definitely gotten requests for being able to open multiple folders in the sidebar - I can see why that would be useful for this kind of classroom environment. A workaround would be to create a single folder with two folders inside it - one containing the example site and the other to contain the site they're working on - and then open that parent folder in the sidebar.

The main reason to require opening a folder is so that we know how to scope certain operations, like Quick Edit and JavaScript code hints, that look for related files. For Live Preview, I think it's mainly required because we need to know the server root, so that root-relative URLs inside files that are being previewed are properly handled. We could conceivably make Live Preview work for files outside the opened folder and just assume that their root is the folder they're in.

Leaving this open to discuss at next bug review - I don't think we're likely to change the way the working files area works, but some of these other ideas around multiple folders and live preview outside the open folder are worth discussing as potential backlog items.

[dangoor]

Reviewed medium priority to @larz0.

As we add more features for "projects" (and we already have a few), the presence of non-project files in the same Working Set (with no distinctive visual appearance) makes it difficult to see that a command you run is not going to affect one of the files you've got in your working set.

[larz0]

We could give it the same-file-name treatment in the working set. E.g instead of showing the file path it could say "non-project file".

Thoughts?

[jdittrich]

@larz0: Where is the path currently shown? Possible this is best talked about having some mockup.

I talked to some of my students; they were not aware that only files in the current project folder get live preview, so there should probably be some sort of help/reminder for that.

UI-Idea(s) One way would be a non-modal panel as a way to give unobstrusive information. In the mockups below it would show when one clicks the no-live-preview indicator in the currently opened files list. Same could appear in chrome if one live-previews a file that is not in the current folder (not shown, but same principle). The wording would need to be better possible with some hint what one could do and a "show me how"-button instead of "help".

[larz0]

@jdittrich something like this:

https://f.cloud.github.com/assets/1067319/906320/1d6e757c-fc8d-11e2-9e4c-ef0c6c92dd62.png

Right now we use twipsy tooltip for live preview messaging.

[jdittrich]

@larz0 I like the idea of providing the path but the path would be useful for non-project files too, so I'm unsure if that is a good way to indicate. But yes, in general I favour an indicator too. From my experiences some notification/help for the use of the project folder is needed too (I will continue to test user's concepts of the current folder soon and see if that supports this or not)

[jdittrich]

I did some further research on the student's understanding of the interface, I asked 6 of them about what the elements in the left bar are and what they do. Working Files

• two could clearly articulate what the currently opened files are
• the other described it with "my project without images", "pages I have linked in my project" or "main files"
• all seemed to be able to use it

Current folder

• two had a matching mental model for the current project folder, they described it as a folder and noted that it showed all files there.
• Others described it as: "I have no clue", "the part where images are", "files on my HHD"

No one mentioned that the current folder enables live preview and other features for it's content.

I have to mention that the students did not have any programming experience before. On the other hand all got a thorough introduction to brackets interface (including the live preview feature) and beginner’s problems can be a more obvious indicator for issues pros have but which are resolved easier for them.

Conclusions: See above for suggested live view indicators; I wonder as well if the currently opened documents should be tabbed, as this is a well known UI standard.

[marcelgerber]

No one mentioned that the current folder enables live preview and other features for it's content.

Have you ever told them of that feature(s)?

I wonder why the couldn't recognize the current files at all, such a tree is quite common and it should be obvious what it contains. What do they study?

[jdittrich]

Have you ever told them of that feature(s)?

yes. (I'll correct above)

Which grade are your students in?

University, mixed terms.

Tabbed UI Mockup: (I know that this is not optimal, especially regarding the than free space in the left panel) Updated 3.1. "left panel" was "right panel"[sic!]

[marcelgerber]

I like your design idea from above, with the broken thunderbolt. With the right tooltip (This file is not a part of your current project, it was added from an external folder. You can't live preview it) and a little hint (similar) while the file is open, this could be self-explaining. And for the difference between working files and current folder, should we add something to the Getting started content? This may help a bit (but I don't think your students did read the Getting started content).

I don't like tabs that much as they get confusing with > 10 (working) files and scrolling them is not the best solution. We now have much UI tools to help identify the file in the Working files (full name, folder name as soon as there is more than one file with the same name, ...), which may be too much for tab view.

[asbruff]

i agree with @SAPlayer for what concerns tabs. They're good when you occasionally surf the web, but when you're working on a project you will be rarely under 10 files. Think about our screens: most of all are horizontal. This means that we can "waste" a little portion on the left or right side without affecting the view, but adding a tab bar would decrease significantly the viewing space (and it will be uncomfortable). If it's possible i would add a voice on the view menu to choose between the tabbed interface or the side panel.

[marcelgerber]

@asbruff That's a good idea, and with the new preferences model this setting can be different for each project :thumbsup:

[larz0]

@jdittrich I think there's a horizontal tabs extension.

[jdittrich]

@larz0 Thanks, I'll have a look at it.

The tabs are not my personal concern, I am well with the current interface. (I think like you that tabs have some drawbacks too)

It was a suggestion regarding 1. the usability principle "Consistency and standards" applied to multi document interfaces. 2. as a way to get a mapping between opened files and current folder that bringing the model of the application and the/my observed users in sync.

For 1. the current way is problematic imho, as tabs seem to be the de-facto standard in Multi-Document-Interfaces (Browsers, Photoshop, Sublime, gEdit, just to name a few) and previous experiences determine usability a lot. 2 could naturally be solved in a different way, e.g. with the suggested thunderbold, the hints and a more "folder-like" appearance of the folder part.

[marcelgerber]

@larz0 Just a little idea, should we maybe add a tooltip to the Working Files text (above the working files) to display a little info what is listed there?

[larz0]

Finally have access to a laptop :)

Live preview message should look like this, ignore the text:

[njx]

For "non-project file", how about "file outside project"?

Also, there's a larger issue that we aren't really consistent about our use of the term "project"...really the only place we use it is in "File > Project Settings". But the main command is just "Open Folder". So people might not have a strong sense of what the "project" is. Something we might want to clean up in the future...

[larz0]

@njx how about "external file"?

[dangoor]

"external" to what, though?

While we do have the lightweight editor aspect of being able to just "open a folder", I do think it's to our benefit to make a "project" more of a thing that people think about. There's no crazy ceremony and wizards involved in creating a project and they don't need to live in a specific place on your drive, but there's already a fair bit of behavior that Brackets builds up around that folder you open.

I'm personally in favor of growing our use of the word project (which just means "that folder you opened", but it's easier to place in UIs :)

[njx]

@dangoor Yup, I agree.

[larz0]

@dangoor @njx how about "outside of the project"? I just realized we don't need to include the word "file" because it's already pointing to a file :)

[jdittrich]

@larz0: I agree

@dangoor wrote:

I'm personally in favor of growing our use of the word project

Yes, one source of confusion could be, that the "project" is not often explicitly visible (e.g. as term), but an important concept.

For a start: labeling the folder/project view would be space well spend in the interface and probably requires only minimal code changes. (Usability Heuristic for that: Recognition rather than recall[ing that this is the project folder])

[larz0]

We could do this:

[jdittrich]

I suppose that it it is a step forward but it makes a lot of sense usability-wise to actually use the term in the Interface that is visible to the user without him/her clicking on an element which purpose is probably unknown to him/her yet. In usability terms, we probably need ›recognition rather than recall‹ and ›modelessness‹. So it makes sense imho to use the space for an immediately visible title. (or something else immediately visible and comprehensible).

In addition, having a title would be coherent with the Working Files – they have a title too.

[larz0]

If the initial "Getting Started" folder were called something like "Project - Getting Started" then we won't need to clutter up the project section with the label.

[jdittrich]

After looking at the mockups, I don't think that the label adds clutter. I suppose the existing "Working-Files" label does no bad either. Seen in a different way: Adding a "Project Files" label adds visual consistency and as brackets has a neat color scheme and UI elements, it will fit aesthetically in the UI while providing a clue for newbies and pros alike, who will probably have a even better experience with brackets if they can orient themselves easier. But I am happy with any solution that makes it easier for the user, and the Folder-Name solution is better than the current state.

[larz0]

"but I would prefer if the clarifying elements are placed in the UI itself as it would be more consistent and not easily overseen or forgotten, if the folder is changed."

I'm not sure if I follow you. If the user changes the project then what is overseen or forgotten?

[jdittrich]

uh, sorry, I deleted that from the comment as I found it confusing as well. What it was referring to was this: If the hint (that this is the project folder), is part of the folders title (if I got that right, the name of the initial Folder should be "Project - Getting Started") and you change the folder and come back, you don't have the hint (and a prevention of forgetting) about its functionality no more (As the new title would not contain "Project -" any more, if that’s not meant to stay) . But I found that explanation too confusing and not a core thing, so I got rid of it :-)

[larz0]

Here's my recommendation, files opened in Working Files that live outside of the project folder should have a "(not in project folder)" label after the file name to avoid confusion.