The Developer’s Duty

Android has an file system browser app. Windows Phone and iOS do not.

Some sing the praises and many wish for the other two to implement a similar built-in app. Often they denigrate Microsoft and Apple’s decision to hide it, for phones and tablets certainly still have file systems. Why remove functionality? Especially something as veteran as the humble file system browser?

For as far back as most tech-savvy folks can remember there has always been some incarnation of the file system browser. In fact, the very metaphor of files and folders has remained largely unchanged for nearly three decades. The nostalgia and comfort associated with such a familiar concept cannot be understated.

But the only reason we’ve been working with file systems up until now was largely due to the complexity problem.

For a long time computers were dumb and slow. Only in the last few years has modern computer hardware gotten to the point where an average, budget build from Walmart will still probably be vastly more power than any typical home user will really need. When was the last time (outside of gaming) you worried about “minimum system requirements”? Oh sure, the market for boutique-style powerful graphics cards, 7.1 audio, and beefy six or eight core CPUs still exists, but it is (and, arguably, always was) largely relegated to the shrinking enthusiast market (aka “PC gamers” and, more distantly, video editors and other heavy multimedia stuff).

I should know. I have been building and constructing Frankenstein computers since I was a teen. And I still find myself reading Tom’s Hardware benchmarks and the like. But even I have found that after building my last computer, it has so much more power than even I need. Other than possibly upgrading the graphics card in the next year or two to keep up with games, I can’t foresee needing more power any time soon for the things I typically do.

We’ve also wrestled with the fact that writing good software is hard. It takes skilled technical folk many man-hours to complete. We have an entire profession and college track. As computers have gotten more powerful, so too have the lines of code grown exponentially. Doom was developed by a handful of folks at id for a minimal budget compared to today’s multi-million dollar projects with credits at the end as long as most Hollywood movies.

Writing a complicated automatic file system wasn’t high on programmers’ lists, of which there were few anyway, when all this desktop stuff began.

That isn’t to say that file systems aren’t complicated. They were and still are today. But they are also kind of a minimal requirement. The OS has to have a standardized way of accessing long-term permanent storage to do the types of useful things we expect. Exposing that underlying requirement as a sort of office file cabinet, with folders and documents, was a pretty ingenious metaphor for helping someone wrap their heads around bits being written to and read from magnetic platters.

But this is a skeuomorph that has grown long in the tooth. It was a metaphor needed only because we chose to expose this necessary underlying system to the user in the first place. Sure, we had our reasons of time and manpower being limited as previously stated, but regardless here it was. The metaphor also quickly broke down under even common situations. Take the classic mistake most rookies cannot be faulted for making:

1. “Open” a file in Notepad – okay, this is kind of like taking a document out of the file cabinet and putting it on your physical desk (in this case, the similar desktop metaphor)
2. “Edit” that file – so, like, write on it with a pen or pencil, or possibly use the typewriter on said desk to make changes
3. “Close” the file – put it back in the file cabinet
4. ?? But wait, Notepad is asking if I want save or discard the changes? What? I already edited it!

Here we have the mental disconnect. What is actually an in-memory copy that needs to be flushed to disk, overwriting the previous copy, doesn’t fit the mental model.

You see file systems, actually, are a really technical feature that is confusing to anyone with only a basic understanding of computers. And unfortunately, the file system lives on and begs them to learn its idiosyncrasies to this day.

But why should they have to learn it?

I have a basic understanding of how a car works, but I also know that even my limited knowledge on the matter is not required to be a good driver. My car, which is several years old even, lets me know when to do the basic stuff so I don’t have to understand why oil is needed for an engine or how it can get dirty. I just know to take it to somebody when the lil’ maintenance indicator says to.

To be sure, there are many reasons why knowing better is useful, I am not discounting that, and it is true for more than just cars and computers.

What I’m really getting at, though, are barriers to entry.

As developers of software, we exist as the “experts” who understand the ins-and-outs and can even write the instructions to control these mechanical wonders. We can morph them from glorified calculators into useful devices for the layman.

As developers, it is our duty to make computers accessible.

I don’t think we are morally obligated, per se, but rather that duty drives our professional existence. The company that makes things the most useful and accessible is typically going to be the more successful one, which in turn means money to pay more and better developers. Companies that don’t, well… they are in danger of losing customers to competition.

This is an incredibly simplistic reduction, I admit.

At any rate, I see things like the hoary file system as being ripe for change. Better that we avoid it and make learning it unnecessary. This may involve hiding it entirely, as two major mobile operating systems have done.

But hiding it or replacing it is hard work for us. It requires a lot more design and thinking and coding, because either way we still need a file system in there somewhere, only now further abstracted from the user’s point of view. This, however, relieves them of needing to learn about it in order to make use of their device. It brings us one step closer to making computer devices that much more accessible to people like your mom who have neither the time nor desire to learn.

In fact, one of the most beneficial things about the recent mobile craze has been forcing us, both application and operating system developers, to think about removing a lot of those relics of the past. Think about some things most modern mobile phones try to hide from you:

• The file system
• RAM
• Multi-tasking
• Boot/startup and shutdown

Save for Android (and even it only really tosses you a bone with that app pictured above), they try to hide the fact that there is an underlying file system. No worrying about folders, organizing files, or what have you. All of that work is, ideally, meant to be handled automatically by the OS or the individual apps themselves.

Memory and multi-tasking are abstracted by automatic suspending and resuming of apps, moving away from our long-held concept of application “windows” that require manual moving around and closing/minimizing/maximizing. Indeed, virtual memory already was a step in this direction on the desktop, to help share limited memory by harvesting memory from applications that are idle or currently unused instead of telling users “Sorry, you can’t open Word right now, try closing IE and RealPlayer first to free up RAM!” And all of this was already an improvement over DOS’s model of “You better hope this all fits into 640KB, buddy!”

Even the whole power management thing, where devices tend to favor “always-on” approach while still being efficient on batteries instead of assuming a constant never-ending power source from a wall socket. This has driven the way we write apps (push notifications, background refreshing and syncing, occasionally connected approach to data sources) and driven CPU designs to be dramatically smarter with automatic clock speed adjustment. No more actively telling Windows to “sleep” (which, again, we had started towards with explicit laptop support for sleeping on lid close somewhere around the time of Windows XP), the whole OS and CPU just kind of intelligently and quickly switch between dramatically different power states.

Of course, the challenge is always in the implementation. And while the goals may be simple, we can certainly argue and disagree as to the efficacy and success the various mobile operating systems have had so far. It will be a difficult road, but I think abandoning things like a file system browser will be ultimately for the best. However, it will require something even better in its place.