Hacker News new | past | comments | ask | show | jobs | submit login

So... what about my scripts? Should I have to load some specific manager - iScript - in order to access my creations? Just because 'the filesystem is dying'? What about my store of .iso files? Do I need iIso?



Quit trying to get everyone off your lawn and accept that you are a (presumably) some kind of developer. Computers are not made just for your needs. The needs of the many outweigh the needs of the few or the one. In this case, you'll eventually have to be running some kind of developer tool to have this kind of access. This is probably appropriate. The average computer user (of any mainstream OS) has as much use for the ability to manage "scripts" and "ISOs" outside of a purpose-built application for using them, as he does for a C compiler.


File manager as a developer tool... The very idea makes me want to chase somebody off my lawn, but it does sound plausible. Every time I work with an application that insists on managing things on its own, I can't help but ask "but where _are_ the files??". I guess there is this notion that files are what's "real" in an otherwise ephemeral system. They are what you run, they are what you store your pictures in, they are what you recover from a busted harddrive.

Normal users seem to be very comfortable with the idea of unspecified magic though.


Quit telling me what to do. Quit sucking down the Apple "There is only one way" philosophy. That there is constant complaints at Apple's UI decisions shows that even in UI, there is not 'only one way'. I much prefer the Linux way - "choose how you want to be" - give a reasonable default, which can be tailored.

To try and paint computer users as being in two camps 'normal' and 'developer' does everyone a disservice - there's much more variety in users than that. Here's an example - there's a lot of gamers that like side-editing save games, yet they're not developers. Where to they fit into your dichotomous view?


I think people who need to manage files outside of a particular application will become the exception, not the rule. As long as you can access the underlying file system when you need to, I see no problem with most people not having to care about it.


How do you move photos from Alice's computer to Bob's computer? "Check out these"? With the concept of files, you can move photos/music/whatever in a number of ways - thumb drive, network shares, cloud. If you only work through 'photo manager' applications, how do you do it? What if the creators of the photo manager didn't want to support thumb drives? What if the way the photo managers on the different devices use different ways of referring to the photos?

I think 'regular' users have plenty of use for understanding the filesystem. I also think that it's okay to have some degree of expectation for the user - dumbing it down for the lowest common denominator is harmful (look at politics!). What do you really gain by alienating the power users?


You're still thinking of exceptional cases. Photo managing applications have, and will improve, native ways of sharing the photos, even if it's as simple as sending an email.

I see no reason why making the common case simple (not "dumb") means you have to eliminate, or even alienate, the power users. Frankly, since I started using a Mac, iTunes and an iPhone, I stopped managing music files. And I think that's great. Files are an implementation detail. What I want is music or radio programs, not files.


It's an error to simply transfer "it works for music" to "it works for everything". That it works for music is largely because sharing media files is verboten in our Brave New World - sharing is not a problem that needs to be solved there. But sharing non-media files between users is not an exceptional case, not even remotely - it's common as muck in business.

The idea that the 'normal' user is only a home-based casual web-browser/photo-taker/music listener is misleading from the outset.




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: