The conversation flowed basically like this:
- point out a target area to improve
- enumerate possibilities
- settle on which ones to try
- have Aaron code it, screenshot it, upload it
- have Celeste and the others examine the results
- rinse, repeat
The eleventh iteration didn't result in a code/upload step, it's my TODO for next time I spend an hour of time on this: put the same label on the places sidebar as we see in Dolphin to make it obvious that this is synchronized across KDE apps (Dolphin, Gwenview, Kickoff ..)
Once I find time to do that, then we'll schedule another lovefest on irc and subject
If you'd like to see what the process looked like visually (which probably doesn't make as much sense as it would with the discussion that went with it) ... here you go:
- First Iteration
- Second Iteration
- Third Iteration
- Fourth Iteration
- Fith Iteration
- Sixth Iteration
- Seventh Iteration
- Eighth Iteration
- Ninth Iteration
- Tenth Iteration
(Before readers start complaining about the encoding widget, that's from KatePart which I use for testing since it is fast to start up and adds more widgets to the dialog, giving us a sort of worst-case scenario that also exercises more features of KFileDialog. The default dialog obviously does not have an encoding drop down.)
While this isn't a finished product at the moment, I thought some of you might find it at least interesting to see the development process we (developer, artist and usability specialists) go through together.
Or maybe this is a really boring topic and I just find it interesting because it's what I do with my life. ;)
58 comments:
This is probably a personal preference but there doesn't seem to be any focal point with the dialog. It's like everything is just sitting there. Probably has to do with the fact that thereis no separation of the various components.
I wouldn't mind seeing a combination of #3 and #8
Another thing, how often does the average user use the "Encoding" options. I'd move it to the options/settings drop down.
@mike: katepart is an editor optimized for coding and similar complex tasks where encoding is important; so hiding it away isn't particularly useful, and the impact it has on the dialog is pretty nominal.
still, try not to focus on the encoding option, because it's really not specifically relevant to this task at all. it could be any additional widget there from some random application: KFileDialog's design needs to allow for that use case gracefully.
so exactly what that extra widget is, for this task, irrelevant. =)
I hate to come across so negative again, but progressively I liked the iterations less and less.
I'm not a fan of moving the new folder and config icons away. It doesn't seem to make sense.
I think it only makes sense to drop the breadcrumb nav down to a seperate line if you're trying to make room to squeeze something else in (search?).
The alignment on iteration 8 looks a little weird. Compare the box around the home icon with the box around the other icons. Why is there such a noticeable height difference?
The whole dialog does seem to float a bit. KDE 3 featured an abundance of redundant dividers. KDE 4 seems to abandon dividers almost completely.
I'd like to see the config and new folder icons moved over to the left with the other icons, and then put a search box in the upper right. I'd also like to see the top of the dialog tightened up a bit.
I'm posting from a Windows box, but let me grab a comparison screenshot real quick. I'll post again in a minute.
@enderandrew: "you're trying to make room to squeeze something else in (search?)"
i actually say exactly that in the entry. maybe you looked at the screenshots, but just skimmed through the text in the blog entry? =)
"Compare the box around the home icon with the box around the other icons. Why is there such a noticeable height difference?"
it's different widget style, one that doesn't do such a great job on that.
as for the top icons, i also noted in the entry that i need to get rid of the toolbar widget and just use a regular widget.
"I'd like to see the config and new folder icons moved over to the left with the other icons, and then put a search box in the upper right. I'd also like to see the top of the dialog tightened up a bit."
ok, now i'm convinced that you didn't actually read the blog entry text.
http://img136.imageshack.us/img136/4568/screenshotyy1.png
In that screenshot you can see a fine divider line between toolbars. Toolbars also have a nice gradient effect.
Compare it to:
http://plasma.kde.org/media/kfd_layout_breadcrumb10.png
In that pic, the whole window, including rows of icons and the nav bar have one flat color. The places bar does not vertically align with the small icon bar.
There is a large gap between the small icon bar and the nav bar.
I thought Pinheiro did some nice mockups where areas of a window/dialog would be seperated not by hard traditional divider lines, but by a tab with a fading gradient effect?
http://www.nuno-icons.com/images/estilo/new%20style%20big%20small%20window.png
And while I link a really old mock-up, whatever happened to the concept of the stark green progress bars? I really liked several of the concepts he did.
It's better than it was before, but I agree with Mike. When I look at it I always get confused for a while about how I should go about doing what I want. These are some thoughts :
1. 90% of the time, when I fire up this dialog I want to navigate to a location that is already in the Places section. But I almost never think of this in advance, because hey ... I'm obstructed by something, be it thoughts or discussion. The result is that my first glimpse of the dialog has to do with the files and not the Places section where I should look instinctively. This happens fast of course, but still it leaves me a bit annoyed inside :) Why does this happen ? Well ... the Places section does not stand out at all. It's in the middle of a fully grey window. Same color, same texture, same "height" as everything. No significant border. It could be red and ugly but I would notice it immediately. I hope you understand what I'm saying.
2. The labels "Name", "Filter", "Encoding" take space from the Places section. I feel they don't belong there. The quick navigation should be an entirely separate part that stands out.
3. Is it possible to also use a url navigator ? I find it much faster.
4. When I navigate in the filesystem, does the "name" textbox loose focus ? Why have to click on it again and again ? Obviously, I'm finally going to write something there, so it should always have focus.
That's all I can think for now. Thank you for your hard work :)
@aseigo: You mention there is space for a "search edit". I read that. I'm not entirely sure what "search edit" means, nor exactly where it is supposed to go save for somewhere up top apparently.
I read your post, just like I read every post fully. That is why you didn't see me complain about the encoding drop down in either blog entry like everyone else. Just because they aren't reading the posts, that doesn't mean I'm not reading them.
I liked the dialog you posted in the last blog entry better. I think these iterations seem to be getting worse, and again I said that it only makes sense to move the nav bar down to another line if you intend to put in a search box.
Right now the spot appears to be between the nav icons, and the new folder icon. That strikes me as rather odd. If you put the search on the far right, it stands out more, and it makes for better logic. I don't understand splitting up the nav/new folder icons.
Hi,
in some iterations you had a much smaller size. Was that just coincedence, or is the size of the dialog also a property of the iterations?
If so, I'd strongly vote for the smaller default size. There are often complaints about "too much wasted space" in kde which I share for some cases.
Here, in the last iteration, the dialog is 840x512 pixels. This wouldn't fit on my eepc in height.
even if it would, from a personal perspective I would say it should be much smaller. small icons & less unused space should be the default for all dialogs in my opinion.
I use a setup of 2 22" screens with a total resolution of 3840x2160 though I still would vote for the small & space saving default. not only because of the little eepc...
"in some iterations you had a much smaller size"
@Goliath23: Some of the dialogs were from Kate (like the first iteration) and others (like the second) weren't. The dialogs are different in a few ways. The places icons were smaller in the non-Kate ones, and also the Kate ones had an encoding drop down.
I believe since the overall dialog was larger, the places icons scaled larger automatically.
Didn't realize that the encoding piece was an application specific addition. It does make sense for katepart to add that option. Not so sure it should be that prominent. To me that seems like and "Advanced Options" type of thing and not a "front page" thing.
How many people have been surprised when they clicked the 'Location' area? I know when I first saw this dialog I was thinking, "Where do I type in the path that I want to go to?" I hate Gnome's method and thought KDE got it right. I think it should be a little more obvious that you can click on the location to enter the path directly.
goliath, to quote from the post:
"You may notice in some of the shots that we looked at the results using different widget styles and dialog sizes as well."
Letting the places bar run through to the top of the dialog was my first idea when i saw your last mockup. Now that I see it, I'm not sure if it's better or not. Makes you realize just how hard interface design really is.
Went back and read through the original post again. Some how I missed the text about the encoding widget after the links to the images. :( Sorry...
You are changing its layout while real problems are left open:
https://bugs.kde.org/show_bug.cgi?id=160973
https://bugs.kde.org/show_bug.cgi?id=119775
Sadly, KDE is going the wrong way. :-/
Just to put another mockup with an even more dolphin-like file selector :
http://pix.nofrag.com/2/b/4/78145b9c91c9f7cd5e816a2d2b516.html
I think displaying button labels by default is a good thing, it's clearer.
Nice work! However I do agree with Nick that the Places area should be the initial focal point of the dialog, and that it should stand out somehow. Kind of like this:
http://dose.se/filediag.png
but of course by someone who isn't a lousy designer like me :) (that one was your 10:th retouched with Inkscape).
Next time try with a VNC session. Lot less of uploading files! ^^
In screenshot 3:
I think if you move down the Places panel and align the Address bar to the left of the window it will look much better.
Also, I think the interface will look real cluttered and unorganized if you stick the Search bar between the Refresh and New Folder buttons.
@elvis : really nice !
The Name, Filter and Encoding QLineEdit don't need to be really wide, so their labels should fit under the iconview, letting the places panel expand vertically (cause this one may require more space)
Do we need filter and encoding? I'm use this feature maybe twice per year :) So I would hide this fields by default.
There is interesting posts on file dialogs here:
http://insanecoding.blogspot.com/2007/03/file-dialogs.html
http://insanecoding.blogspot.com/2007/04/file-dialogs-take-2.html
http://insanecoding.blogspot.com/2008/01/kde-4-review-insane-style.html
@Goliath23: Some of the dialogs were from Kate (like the first iteration) and others (like the second) weren't. The dialogs are different in a few ways. The places icons were smaller in the non-Kate ones, and also the Kate ones had an encoding drop down.
oh, I missed that. in that case however, I think the kate file dialog is still to generous with the available space.
Haha neat. on your last post when I was saying it was cramped I suggested exactly this layout, but you said it would waste space.
I made a mockup of it, but then forgot to upload it in the end.. Good to see that eventually we had the same ideas.
I like the idea of splitting the configuration buttons from the navigation buttons (this makes more sense than the current situation), but I am afraid that if you put a search box in between, then the dialog will look ugly. So maybe it would be better to put the configuration buttons next to the navigation buttons but with a separator in between.
BTW unlike an other commenter I progressively liked the iterations more and more ;-) (except the one with the ugly widget style that puts a box around the icons).
I however agree with the commenter that there are too less dividers in KDE4. Yes, in my opinion, there exists such a thing as "too less dividers" ;-) I guess the reason is that every movement (too much dividers) generates at a certain moment in history its opposite (too less dividers). The Oxygen widget style is beautiful, but it has one serious (IMHO) drawback: the windows and dialogs seem to be chaotic, everything is located somewhere and there does not seem to be an order in it. For example, in Dolphin there is no clear distinction between the menubar, the toolbar and the location bar; there are justs words and icons one next to the other and one below the other that seem to trigger different actions when you click on them. For someone who has to learn to use computers and learn the notions of menubar, toolbar, ... this must be terrible. Similarly, in the file dialog, the places area does not seem to be an area on its own, it's just a bunch of words with icons that are located to the left of the folder view. A box around the places area would help (I know that you are planning to put a "Places" label as in Dolphin, I hope that you also add the box as in Dolphin); then the "Name", "Filter" and "Encoding" labels would not seem to be invading the places area (it's a good idea to place these labels there BTW).
Thanks for your great work and for keeping us informed.
@Enderandrew: "There is a large gap between the small icon bar and the nav bar."
getting rid of some of these extra spaces there is why i need to replace the KToolBar with a normal QWidget.
@Nick Lefkaditis: "Places section does not stand out"
yes, as i noted i need to add a label to the Places category, and i plan to make it pretty much identical to what we see in dolphin right now.
"The labels "Name", "Filter", "Encoding" take space from the Places section"
then where do they go? if you say "aligned with the file listing", then that leads to new problems with alignment and visual focus.
"Is it possible to also use a url navigator"
of course; just click to the left of the breadcrumb bar. we could probably also add this for Extra Clarity(tm) to the configuration menu.
"does the "name" textbox loose focus"
yes. this one is a bit tricky to fix as it involves handling focus properly in several different situations. i agree that it shouldn't lose focus as easy as it does now, but i don't know if i'll have time before 4.2 to open that can of worms =)
@Goliath23: "in some iterations you had a much smaller size. Was that just coincedence"
it's not coincidence at all; we change the size of the dialog and the widget style being used (as well as the host application!) to show the dialog in different states. we don't want a dialog that only works when it's really big, or one that looks bizarre when it's not really small ... so we shoot and discuss the dialog in various states.
@Andre: "Letting the places bar run through to the top of the dialog was my first idea when i saw your last mockup. Now that I see it, I'm not sure if it's better or not."
we'll see if making it look like dolphin's sidebar helps. i'm hoping (and thinking) it will.
"Makes you realize just how hard interface design really is."
tell me about it =)
@vedranf: "You are changing its layout while real problems are left open:"
so, tell me: why do you think that fixing interaction bugs and working on usability are mutually exclusive actions?
i don't like it when people accuse based on assumption, because often, like in your case, those assumptions are wildly wrong.
on the usability list, we have also been discussing interaction bugs and Peter will be working on them.
have your cake and eat it, too.
@flouzy: the places section will end up looking a lot like that; i don't like the lack of spacing in the toolbar and i find in this case the text to be just too much visually. the icons are not very mysterious and have tooltips. this is a situation where text is actually not better imo; and i'm the one who threw in the text under buttons on toolbars by default for apps ;)
@elvis: i want it to look consistent with dolphin, actually.
@paurullan: ksnapshot makes it pretty easy, and i don't really need the bandwidth and cpu usage of 3 people vnc'd into my machine while i'm compiling and what not =)
not to mention i was involved in other conversations at the same time that were private.. so .. yeah.. =)
@yman: "I think the interface will look real cluttered and unorganized if you stick the Search bar between the Refresh and New Folder buttons."
the search bar will go to the right of the configuration button, with a spacer between the nav and the control buttons that will disappear to 0 pixels as the dialog shrinks.
@Andre: let's just say that i'm very glad that the insanecoding blog writer isn't designing UIs i need to use on a daily basis. i'd also suggest that he just use the old school url edit in the file dialog and konqueror as his file manager as that's probably a lot more in line with what he expects.
maybe that's even why we left those things in place? ;)
@Leo_S: what makes it work, at least for me, is that the nav/control buttons aren't on a line by itself but share the space with the places bar.
and as the search edit wasn't actually in the original requirements (i wasn't even tempted to implement that the previous day), it was even more of an issue.
@Aaron :
"then where do they go? if you say "aligned with the file listing", then that leads to new problems with alignment and visual focus."
Well, that's a question :) My opinion is that first one would have to make a choice between logical separation or presentation of the elements of the dialog. In the current implementation the latter is preferred and you actually might be right. But it's bugging me ...
First, I think that although you avoid alignment problems with the textboxes (if I understand what you mean), you create alignment problems with their labels. Plus the labels (current file properties) clearly don't belong under Places (quick navigation folders). So, in my mind, choosing logical separation and dealing with just presentation issues would be better than choosing presentation and dealing with both kinds of problems.
Some ideas : maybe the labels could be put above the textboxes. Maybe we could have right aligned and equally sized textboxes, with left aligned, non-intruding in Places section labels. Or maybe the labels could be put inside the textboxes in a fading font and disappear when the user inputs data. Or be joined with the input data (eg "Filter: All files").
Something else I've thought of is the position of the navigation arrows. In a browser the always are next to the url bar. Why not take advantage of this and place them in a totally new position ? Also, what would be the use case for the Refresh button ? I've noticed that Dolphin refreshes automatically and if that's the case for this dialog, then isn't it a bit "unneeded" ? :)
About the New folder icon. I've never really used it before and that's not only because I have to target a small space, when I can just right click in the big white area. In my mind I've never associated this icon with the functionality of that bar, which is "navigating". I actually forget it exists. Doesn't it make sense that if I think "folder" I'll look in the file view and not in the "navigation" bar ? So, why not remove it and instead add the same in the file view as the first item to always be viewed ?
Okay, that's all for now, it will be morning before I know it :)
Sorry for spamming you, but I think I may have not been clear when saying "First, I think that although you avoid alignment problems with the textboxes (if I understand what you mean), you create alignment problems with their labels."
It's obvious that the labels "Home", "Network", "Root", "Trash" of the Places panel are left aligned, while the labels "Name", "Filter", etc are right aligned. Sure, they have nothing to do with each other (which I also see as a problem), but still they're in the same vertical line. The visual result is ... awkward.
flouzy: I like your mockup. I don't like the labels on the buttons, but frankly so long as I can change it, I don't care that much. I don't know if you're using a different English locale than me perhaps, but I do believe the correct spelling is "forward". Is "foreward" the correct spelling somewhere other than the US?
I really like the folder icon in front of the nav bar. That will help it pass the grandma test. I really like the dividers. I like that the mock-up is well aligned. All around very good!
elvis: I like what you're going for here. But that effect may be a bit much. I'd have to see perhaps some variations not as drastic.
@nick
"Some ideas : maybe the labels could be put above the textboxes."
That would make the dialog too tall (or take too much space from the file listing, which is after all the most important part). On the EeePC you only have 400 pixels of height to play with.
"Also, what would be the use case for the Refresh button ?"
Check the previous comments for why its there. Local filesystems refresh, remote ones don't.
Can someone please explain why the config icon is on the far right? How often are you going to change the settings here? Once or twice? It is almost common practice for the search bar to be in the far right in many different systems I've seen. I think people expect it to be there. The corner attracts the eye, and it is easier to spot there. I think sandwiching icons around the dialog will make the bar look congested overall.
I'm assuming the icons were moved over to the right because someone thought it would be an improvement. I just don't understand how it improves anything. Would someone care to enlighten me?
Thanks for showing the process of how you design these things! It's clear from all the experimenting and debating over details that a lot of thought is going into the design, which is probably why KDE turns out so great.
I still think filtering belongs above the list of files, and should apply immediatly on editing the contents. This way, it behaves like most other filters for long lists.
However, I am not sure that I like the KDE 4 file dialogs at all. Although you don't agree, I think the comments in the insane coding blog do have some merrit, even if they are worded badly. I understand that there is thought on usability, but I think that usability is understood in too absolute terms. I think istead that it means different things to different people. In other places of the KDE desktop, this has resulted in choice. Like, in the case of the start menu, people can now easily choose to use another menu (Lancelot, for instance, or the old-school one). Would it be possible to do something similar for the file dialogs in KDE? I think it would be fantastic if the default file dialog could be replaced in the whole of KDE by installing some kind of plug in. Some competition between different ideas never hurt before, I think. This way, users can decide for themselves what they find to be a comfortable file dialog for their needs, there is room to experiment, and thus new and innovative solutions may be tested before they appear in a future default file dialog.
I would serously considder working on such a replacement file dialog myself, if it would be possble to do such a thing.
Don't get me wrong, I really appreciate all the hard work you are doing for KDE, and I think the dialog you are designing would be really usefull for some groups of people. But I think you could avoid a lot of critique from people who have different requirements or expectations by offering them an option to do it differently.
"Sadly, KDE is going the wrong way. :-/"
This is the kind of comment that annoys me. Why couldn't the developers do multiple things at once? Should the drop everything and focus on the two bugs you mentioned? If they improve some other thing, as opposed to focusing on those two bugs, it means that "KDE is going the wrong way"?
Maybe those two bugs are not Aarons cup of tea? Maybe someone else is handling them (the latter of the two bugs is assigned to Carsten Pfeiffer....)? Does that mean that Aaron should not work on the file-dialog at all?
@Enderandrew : my big mistake :)
Don't know if it's useful but i made 2 more attempts with the search box integration...
http://pix.nofrag.com/3/e/0/819ca08936bab0072dd9fbcb3142f.html
http://pix.nofrag.com/5/d/1/e41bf7bf137b2d749cdec840a5fc6.html
"I thought Pinheiro did some nice mockups where areas of a window/dialog would be seperated not by hard traditional divider lines, but by a tab with a fading gradient effect?
http://www.nuno-icons.com/images/estilo/new%20style%20big%20small%20window.png"
I agree 100%. Now, in the past I have been the enemy of separators, dividers and generic "clutter". But I do think that there needs to be SOME contrast. Right now the "places" sidebar is not separated from the rest of the widget in any shape or form. The Pinheiro-mockups are (IMO) an excellent proposal how to handle the situation. You would have separation, without harsh dividers and the like.
Great work. 11 iterations of discussion coding compiling uploading and evaluating in an hour and a half! that's pretty good going. And thanks for blogging it too.
Based on a proposition by flouzy, here goes mine:
http://pix.nofrag.com/f/c/2/0b68f42c060febc1c5e9f80142b0d.html
I just like to say that I do love the insanecoding blog entry!!
Great review. Always consider that!!
Thanks for posting, @Andre!
I liked elvis way to make the place list separated. But wanted to experiment with moving the breadcrumbs up. Here it is:
Breadcrumbs up
Here's two ways of integrating the search input into agateau's variant:
Next to the Filter
On the left side
Great work guys. Im wondering, what about file previews (usually at the side of the dialog). Dolphin has a cool preview pane which contains the tag & ratings, could this be imported into the file dialog?? i think such a pane would help when selecting file(s) in list view & you want to know its properties e.g. size Just my 2 cents.
Dont know if this is implemented but does the dialog support dolphin-style multi-select?
Hmm, what about virtual folders (nepomuk) e.g. would it be possible to include say tags in the places pane to search in nepomuk like "3rd qtr sales report", or better yet, a way to include in places kio_slaves shortcuts e.g. kio_ftp linking to e.g. shared programs, webdav share kioslave or imap folders??
Another proposition based on agateau's:
http://pix.nofrag.com/9/0/8/4f6413d950e3e2fcdcefc46049d9e.html
So, hum :)
Here is a condensed version with and without the encoding widget :
http://pix.nofrag.com/7/9/0/8e7d44f1519b2f70fcab277494852.html
http://pix.nofrag.com/e/7/d/65f4cd43135b7eb982d504c586b1e.html
Always wondered about the encoding option. There should be a way to automatically detect the encoding of a file based on it's special chars. If only ASCII chars are present stay in a default one.
@flouzy:
http://pix.nofrag.com/3/e/0/819ca08936bab0072dd9fbcb3142f.html
This one is very close to what I'd like to see. If the places bar didn't just have a plain box around it, but perhaps one of those nifty 3d tabs with gradients like Nuno Pinheiro was experimenting with, or something like that.
I certainly don't mind moving the filter box over to the right of the name box.
As for several of the other "condensed" concepts posted recently, many of which hide the search bar under places, I don't think they work well for UI design. Yes, they are tight and I like that, but you have to consider eye tracking. What will users see first? Will they find what they are looking for?
I know that Aaron was working on a new shell for low resolution devices like the n800 series. I wonder if some of the dialogs can also be reworked for really small devices. In that regard, I think condensing the dialogs would take precedence over eye-tracking because of the limitations of the system.
Wow, aaron, you're sure getting a lot of feedback! You're practically getting the community to design the dialog for you. (For the record, I like this one the best, although I'd like to see the entire concept of a "file open" dialog reworked once Strigi+Nepomuk are in full swing.)
I feel I speak for those of us with large numbers of file in our folders: I hide the Places panel in KDE4. It takes up room where I'd rather see another column of files. What I WOULD like is the little Places dropdown widget from Dolphin inserted in front of the breadcrumb. That way, users can hide the Places panel if they need the room, but still have all the convenient shortcuts that the Places panel provides. (I know you already said you want to make the dialog more like Dolphin, and probably already planned on adding the Places dropdown widget - but I thought I'd mention it just in case.)
Alright... better late than never!
Here is my take:
Picture 1 (with encoding):
http://pix.nofrag.com/9/3/c/80fb75c052797e20c630a5982eeb5.html
Picture 2 (without):
http://pix.nofrag.com/d/c/b/cdbdd681604ea23d5f347311e864c.html
As you'll notice on Picture 1, i took the search bar in the top-right corner and turned it into a combo where you can alternately select "Search" OR "Filter". Discoverability is good IMHO. It also fits logically in the dialog: all the controls that act on the "file- view" are on top of it.
Also, the "Open" and "Cancel" are on the same line. This is to fit with almost every other KDE dialog I've seen. Why should the file dialog be any different? And as you can see on Picture 2, it still looks great if you use an "alternate button order" like in Gnome or MacOS. And as a bonus, you can see on Picture 1 that the encoding combo fits quite nicely on the same line too. And its also logical: the encoding combo does not act on the "file-view", but on the current file you're trying to save, so it is at the bottom with the name box.
In general, I tried to limit the vertical size: it's under 500 pixels, so it will fit on an eeePC too.
Hope you like it!
Bye!
@Patrice Tremblay:
Moving both buttons to the same line is rather nice. However, the search/filter button takes up space without really providing any space.
In the encoding screenshot, you have the encoding selection next to the open/cancel buttons. I'd rather that filter stay down there. I think it makes sense to type in filter next to where you type in the name. When you don't have encoding, now you have empty space by those buttons, but you're cramping the UI up top.
Here is a really crazy idea. Make the "Name" field one that works for Search, Filter and Name.
If I type in *.jpg it should then refresh the display to show *.jpg files. If I type in kurl then it should then filter/search the results to everything that has kurl in that folder. If there are no results for kurl in the current folder, the main view pane should prompt me to search in another folder, or subfolders of the current location. The name/filter/search bar should eventually support Strigi.
This is a win/win/win for the following reasons. UI is tighter. Use is more efficient that I'm not moving to multiple fields. I type in what I'm looking for in one place. The UI doesn't need to be redesigned once Strigi is implemented. It is powerful, intuitive, and it just makes sense.
@kwilliam: Good point, good idea.
@Aaron: I would like to hear your view on providing a list of recently saved files, and ways to quickly jump to their directories (see my comment in your previous blog entry). In short, I think too much time is spent manually browsing directories to find files saved elsewhere by other applications. I think the best way to solve this is to share a history list.
@claes: I'd like to see the Places bar act dynamically, automatically picking locations you use the most.
That one (Tenth iteration) looks better to me than the version from the previous blog post. While there's a lot of wasted space in the toolbar, it looks at the "right place" and the location bar is no longer as squeezed.
Just registered to leave a comment here.
If I understand it correctly, the path bar is put to the right of the places sidebar so that the connection between the path and the viewed directory is clearly visible (like in dolphin). The search field is going to be put in the top right corner of the dialog above the path bar. I think that the search box should be on the same line as the path bar is because they both show the contents based on the input. Together with the fact that the icons are mostly on top in applications (and especially that the back/forward/up icons are in the top left corner), I would stick with the traditional layout of the KDE file dialog (with the search field in the top right corner). If the lack of the space for the path bar is the issue, then there could be an option to hide the search field.
Also, if the local filesystem refresh automatically, couldn't the refresh button be grayed out? See
That last one by Vin is by far the best i've seen proposed! If the breadcrumb gets too long, intermediate directories should imho be replaced by ellipses, showing the full path in tooltip on hover. Filter could have a lesser prominent position.
I have added a little variation.
Probably not fitted for real use case but I like it and would like to share it.
http://www.kde-look.org/content/show.php?content=88329
@enderandrew: That "crazy" idea doesn't sound bad to me. In fact, it reminds me of the Awesome bar in Firefox - making one field "allmighty" - name field could display not only the history of recent files as you type, but search for it in the system. I'm not exactly sure if it should be the only one way how to search in file dialog - some may prefer the "plain" old name field (awesome bar is not so awesome for others because of similar reasons). I'd add some option for disabling it.
@claes - Although I think the drop-downs of the path and name field suffice, it seems they are not so intuitive in the first place. I agree there should be some history pane.
Speaking of the pane - insanecoding mentioned the folder tree, I think it would be a fine feature as well. There is an interesting feature that came to my mind - clicking the places' folder could switch to the tree-folder pane. Both Dolphin and file dialog could use it.
Sorry to bother Aaron again, but hey, you know what ? I have a new proposal...forgive me :)
I made a pdf version with some comments. Hope it will give Aaron even more ideas.
PDF File
PS : The file is hosted on 2share.com, I don't know if the site is trustworthy...
I like the Vin and Flouzy mockups.
In my opinion, most important thing is:
Opening:
1. Get to right place
2. Find the right file
3. Get the right file opened.
Saving:
1. Get to right place
2. Set right file settings (metadata: rating, commets, tag etc and encoding)
3. Save the file.
I like the idea of "search" bar to be placed to right corner, so it is like on web browser (konqueror, firefox you name it).
What I would like to see, is possibilities to EDIT open/save dialogue toolbar. I would like to add there two buttons to allow me to choose list or icon mode, without going to "Configure" menu. I would like to remove the "Refresh" button (or make it so it will come up only on remote places what does not update). I would like to remove the "Up" "Back/Forward" buttons. I only need new panel.
I would like to move the "places" view to right side as on dolphin I can.
Give us options to modify the GUI ourself like we want and power users are happier. Make them locked by default so novice user does not get them moved without unlockin the panels.
And then important thing again:
-Check that dialog can be used on 400px hight screen.
-Check that "Search:" panel is not just 30px wide, so it is "full" when you type there one word like "Airplane".
-Check if bars can be joined. Like someone suggested the name/filter/search bar. If you really type *.jpg you would get only those files. Use the *nix way to use wildcards. If I type as filename foo*.txt, foo* or *oo.txt I should see only such files as on commandline.
I would like to see mockups with preview on. Someone made preview to right side like on dolphin, with it name on top, what looked nice. It should be moveable too.
I know that making things more "modular" (so they are able to be edited) brings more possibilities for bugs and needs more testing. But I say it is worth of it.
After this dialogue is done. I hope Aaron would check the "Open with...." dialogue. I think it would need samekind filtering as Alt+F2 offers for menu entries so when user writes "show" when opening image from internet, it would filter all other entries away execpt showfoto.
And almost forgot. I was first few times afraid to click "new folder" because I didn't know does it get added to file view, or to "places". Because the "places" has the selection. This at least when in single click mode. And the "places" selection does not get hided when i.e first click the "Documents" and then clicks wanted folder in file view so we ain't anymore in "documents".
Post a Comment