Hacker News new | past | comments | ask | show | jobs | submit login
File manager ideas (evernote.com)
68 points by renat_yv on Sept 2, 2012 | hide | past | web | favorite | 31 comments

These are all completely obvious — idea 2, though, only in retrospect. For a long while I've wondered about how to combine path editing with hyperlinks. Numerous browser extensions have tried various methods: mode toggling, modifier keys, the direction whence came focus, and so on.

The OP's approach is perfect: always navigate to wherever the caret is placed. I would personally drop the ugly gradients in favour of hyperlink-style underlines, but seriously, thanks for an elegant solution to a simple problem.

Hmmm. The Explorer in Windows 7 does this, somewhat better than proposed here (in my opinion) since it eliminates slashes.

There are additional operational semantics that are important, such how you bail out of a bad edit, what happens if you type in something non-existent, and so forth.

I hadn't realized how involved this UI is. People take a lot for granted.

> People take a lot for granted

I would say the average user doesn't understand correctly a good 70% of what's on his screen. Programmers sure do take a lot for granted.

Edit: missing "user".

I wonder if MS was able to patent that functionality in the Explorer in W7. Of course it shouldn't be patentable, but with today's system, I doubt they'll have trouble doing it.

Mixing breadcrumbs with a text field is a dangerous thing to do. Take for example input selections. I click in the middle of the path and then shift-end the cursor. What should I see in the content pane?

Second thing to consider is how it's going to work on the file systems with lag. Anything over-the-network. Not only moving the cursor left and right would generate a lot of traffic, it would also fail to provide feedback comparable to that of local drives.

Third, take a step back and think who would actually use this. For example, the only time I use Location field is to copy current path to be pasted elsewhere. I tried remembering when I actually typed anything except for c:\temp in there and I can't. I'm sure there are people who do type in long paths, but the question here how many of them are there and if the UI should be optimized for their usage. If they comprise a percentage point, then clearly all this optimization is pointless -- it may very well still exist, but it should be off by default. In other words, as nice as this exercise is, it jumps to the design phase without first defining the problems it is trying to solve nor its target audience.


As others have noted W7 has something similar in Windows Explorer, but the field switches between the breadcrumb and text input modes. This looks like a sensible solution, and yet I personally find it fairly annoying in a day-to-day use.

As for typing in the location bar, there is a kind of autocomplete/tab completion mode which is really useful. The behaviour seems to have changed in more recent versions, I think the tab key doesn't work now, as it's a UI control to move focus. I prefer the shell style tab completion, but nonetheless it's a useful feature.

Which reminds me that navigating around nautilus with the keyboard is really a bit of a pain. To be able to do this easily would really help. I noticed in Mint's nautilus the last time I tried it arrow keys would let me move back and forth between the sidebar and the file lists, it may not be the right key to do it - but makes using the file manager much easier.

Regarding search, something that always trips me up in Nautilus is the find as you type feature, which I also love.

If you are in the folder list and you start typing - you can select folders. Say you start typin P-i-c, it will select say your Pictures file or folder. I then go to copy the folder but I'm still in the find as you type box, but I don't notice. I move to another folder view and paste, and find I have done nothing. Then have to navigate back to where I just was. To get around it you have to hit escape first before the copy. I'm aware of how to do it correctly - but I repeatedly trip myself up.

The other issue is the text find tool overlay is hidden in the bottom right hand side of the window, which seems to sometimes escape your eye. And the interface then feels non-responsive. Love the feature, but there's something amiss in the interface.

If you start to type the name of a folder, and it matches something, hitting return will open that folder, which is great, but is slightly out of tune to trying to use say CTRL + C (which copies the text you are typing in the selection box.) The latter is something that you might want to do - not that I have ever done it. But there are two conflicting behaviours here.

Hum, IRIX file manager had both editable path and buttons in 1994 or 95. The buttons were thin,over the path. Seemed quite easy and practical back then, search for IRIX on this page : http://www.guidebookgallery.org/screenshots/filemanager

One of the main take-aways (clickable breadcrumb folders) is already present in both Windows and OS X. In Windows, the current path is represented as a series of clickable buttons, including dropdowns to the right of each folder to show their contents. You can also click to the right of the path to convert it back to text form. The new path bar was by far one of my favorite features of Windows 7, and I use it every day at work where I still have to use a Windows PC.

In OS X, you have the path bar, though it's not very obvious that you can double click each path element. You can also right-click or control-click the folder name on the title bar to get a menu of the path hierarchy.

As for the other point, searching paths, I can personally see that being very useful, but most people expect that a search in a file manager will, you know, search for files. This would introduce a jarring discrepancy.

It's also present in Nautilus, as the article pointed out. It's called "button view".

> though it's not very obvious that you can double click each path element.

Wow, who designed the interface that ignores single-clicks and acts on double-clicks?!

I prefer the default existing. Its the top bar of a file manager, it should be as clear as possible to anyone using it. I don't want to see slashes, and If I want to search, I don't want to have to delete all the text containing the current directory I'm in to start doing so. 'Instant search' works on web-browsers because when you click on the title bar it automatically 'selects' all the text there, so the first letter you type will start a search (after deleting all the existing text in the title bar). This is not how a file manager would work. As you show, when you click on the title bar you want to 'edit' the current title...

I'd rather get rid of the 'back' and 'forward' buttons, which are quite extraneous for most users (browsing a file system is generally not like browsing the web). Agree that 'location' can go though.

Why would you prefer the non-slash version? The only reason I can see a use for it is to either make the path more readable (which could be resolved perhaps with a more readable font,) or that it's designed for a touch interface. The latter which makes more sense.

The button view (not the slash view,) kind of reminds me of breadcrumbs, having recently viewed folders showed (with shortcuts) would actually be a pretty useful addition to Nautilus.

Because it is more readable visually when its separated by whitespace rather than looking like a long string. Maybe I just have different preferences to anyone else in wanting the file manager of a desktop-aimed system to be simple and understandable rather than powerful (I have a terminal for that)...

The slashes aren't the main point really. Its the confusion of not knowing whats going to happen when I click somewhere and start typing that I really disagree with strongly.

Nautilus does change it's behaviour every once in a while. Sometimes for the worse. You used to be able to open folders ala Finder style I think it was Alt and right arrow on a folder, when pressed repeatedly you could open up the folders decendents. This feature has gone, which is a shame as it was great to get a quick overview of the file tree. I now have to resort to the 'tree 'command.

Another feature I always feel is missing is right click a folder, and have the option to create a new folder or file inside the highlighted folder.

Another feature missing from nautilus is being able to do multi-select with the keyboard alone. I think you can do this with the Kde file managers.

These are the kind of ideas every software developer should practice with. Forget the technicalities: the programming languages, the databases, the frameworks. A good piece of software is not judged by its code, but by its interface.

Every software developer should answer questions such as "What can make the experience easier for my users?", and constantly practice with UI concepts.

I talk more about this in my post about how I think "Interface Is All That Matters": http://www.pseudocodice.com/post/27983862986/interface-is-al...

Agree. The difficult thing here though is that it's an intrinsic part of the desktop, and you need to standardize interfaces across the OS, and preferably if they are shit hot (in that you can navigate them easily and barely notice them,) across different OSs.

If you're interested in the development being done on Nautilus (which is bring renamed to "Files" in GNOME 3.6), see these two blog posts:



See the post discussed at http://news.ycombinator.com/item?id=4465904 for more changes in GNOME 3.6.

I hardly use file managers, but some of these points seem quite interesting, I dislike the idea of hiding the search button when you click in the middle of the search field though, this will most likely only make it confusing for the user. A better options is to disable the search button when the user interacts in the middle of the search field(I think that's possible in GTK, isen't it?).

EDIT: Ignore my comment above, I missunderstood the part about the search button in the article.

I think you misunderstood; the OP was saying that there should be no search button, ever, as in (e.g.) Chrome.

Oh, I'm sorry. I'm taking back that then.

I did this mockup a while ago... the list of buttons for the directory hierarchy looks a bit weird and I thought something like this would be better,


And when it comes to monitor layout within Gnome I thought something like this would be good,


The most useful thing you could do with Nautilus is to make it keyboard friendly without having to resort to Function keys, and other odd key combos.

How about Super key and arrows to move between panes of an applicaton side bar, location bar etc. And make it very clear which part of the application window has the current focus.

Give dolphin a try : http://dolphin.kde.org

My first thought was: You'd better not try making those changes if you want to run on mobile. After all, Apple invested sweat and imagination to innovate the idea of a useful user interface and now has many patents on it (US Pat #8086604, among several others).


While we are at topic of file manager - is there a file system manager for ios devices? I mean i want to browse disk of my iphone & see where and how it arranges files

Is it even possible?

They are correct. iFile works great for giving you a Finder styled file manager inside the idevice. iFile is also the best utility for doing things like decompressing etc.

If you want to see the files inside your phone in a file manager on your computer most people go with OpenSSH/Cyberduck. Personally I like Netatalk which makes your device just show up as though it was an external hard drive and breaks down the folder hierarchy the same any Linux distro.

You need to jailbreak first, then install iFile from cydia. It's not free but it works great.

OT: why does this site render so poorly on mobile? You can't even properly scroll.

buttons or shortcut keys to go to sibling folders


He's suggesting improvements. You meanwhile are not constructive. If you prefer other systems over Linux, nobody forces you to use it.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact