No Tabs, Why?

Design by Questions

Socrates, a revered Greek philosopher, sought knowledge by asking questions. The technique forms the basis of any authentic field of knowledge today. Be it science, religion, law, mathematics or programming. An easy way to stagnate your intellectual well-being is by refusing to ask questions. Another word of advise. Successfully stifle your creativity by blindly following convention. "Blindly" is the keyword in the last statement. I conceived Scribes by asking questions.

Questions?

What is the purpose of an interface? Why do applications have menus? Why is manually saving documents necessary? How come applications have statusbars but don't use them? Is feedback really a key part of human interaction? What makes experiences enjoyable? How do people edit documents? How can they do it efficiently? Why do applications question my actions? Why do they ask silly questions? Why do they keep me uninformed? What frustrates people about software? Do Tabs provide any productivity benefits? Why do you need to learn a programming language to configure Emacs? Why do you need to configure applications at all? Why was my girlfriend baffled when I suggested she use VIM for her assignments? Will I get laid tonight? Disregard the last question.

An Application with An Arrogant Attitude

Scribes is an arrogant application because it does not pretend to be conventional. In fact, it seems to take pride in being unconventional. Most people who spend more than 15 minutes with Scribes will be immediately confronted by its rebelliousness. Within 30 minutes of usage they'll either love it, or hate it. Most users have a love-hate relationship with Scribes. If you don't have any feelings towards Scribes within 1 hour of usage, kindly file a bug report. Scribes has a soul that makes is unique among editors. A soul fueled by inquiry.

Man, Pen and Paper

Pen and paper are man's oldest editor. Thus the paper is the metaphor I ascribed to Scribes at its inception. If you are visually mapping an empty paper to an empty Scribes window, we are on the same page. A paper is a single document. When you edit a paper, the paper does not ask if you want to save it. Nor does it beckon you to kiss it to have your writing saved. Isn't it weird that software applications require needless protocols to use them? A paper doesn't have tabs either. Well, there's no need for one because you can only edit one paper at a time. A paper is a single individual unique object that may represent a document. Metaphorically, so also is a Scribes window. I don't view a Scribes window as an application. I view it as a virtual paper. A paper retains its last state and property. So also does a document written with Scribes. If at this stage you are still confused, I'll let you in on the secret. Scribes was not designed with an MDI interface in mind. That's why it does not support Tabs.

The Itch I Scratched

Almost every GUI editor I used prior to Scribes was application-centric and MDI. I loathed them for that. They forced me into a way of thinking that was unnatural. The paper metaphor makes sense to me. Something felt wrong about thinking in terms of applications as opposed to documents. On Linux, I knew of only 2 editors that were document-centric, object-oriented and SDI. One was a note taking application that suffered from poor text processing facilities. The other was an editor with the same ailment. I needed an editor that mapped well to the way I think, the way Psychologist suggest humans have evolved to think. The spatial way. And behold Scribes was born. If anyone told you I had intentions of making Scribes an MDI later in its life, that person has committed a heinous crime. Forgive my hyperbole, but there are a billion and one editors that are MDIs. Remind me, why is one more needed?

Implementation Overhead

At this point, the usefulness or uselessness of Tabs is completely irrelevant. What is relevant is what it will take to revert my fundamental design decision. The response is, a lot! The amount of work needed to implement both an SDI and MDI interface is colossal. When you begin to analyze the cost-benefit ratio, the rational developer will choose either the SDI or MDI but not both. The overhead of implementing Tabs in Scribes is disastrous. And even after I implement it, I will be incapable of guaranteeing Scribes' stability and reliability. Putting conditional statements into forty thousand (40,000) lines of code and making a few hundred objects MDI-aware only to make Scribes buggier is not an idea I entertain even when I'm high. The people demanding I implement Tabs in one hour, day, week or month are in essence demanding I squeeze milk out of stones. I guarantee you, squeezing milk out of stones is easy. I do it all the time, in my dreams. But at the moment I have more pressing priorities, sorry.

Four Hands and Unlimited Resources

So assuming my brain malfunctions and I begin to like Tabs, would you rather I spent months re-engineering and testing Scribes to support Tabs? Or would you rather I spent my spare time on features that actually boost your productivity and improves Scribes' text editing experience? Because when I began to question the convention of Tabs I concluded it did neither of these things.

There's Hope

Will Scribes have tabs? Possibly. It will require a massive redesign or rewrite. I have other pressing priorities and no motivation to work on it at the moment. At least until more important commitments have been met. However, if I wake up tomorrow and a courageous soul sends me a patch that works, I'll gladly accept it.

Tab Myths

The tab proponents have a couple of myths they propagate with reckless abandon. The first is that grouping documents in a single application is somehow superior to grouping documents in a taskbar. The reality is that there's no significant difference. In fact, allowing the window manager to manage windows is more beneficial. Window managers provide sophisticated grouping and organizational techniques that are absent in applications that manage multiple documents. The second is that tabs improves productivity by allowing users to edit multiple documents simultaneously. The reality is that users can only work on one document at a time regardless of whether they use tabs or windows.

Tab Flaws

Tabs don't scale well. Try opening ten tabs in a window. Not only does it become difficult to select or manage documents, most implementation of tabs do not provide facilities to search or sort documents. There's a diminishing returns as you open more tabs. Finally, MDIs do not map well to the way humans think. What metaphor can we ascribe to MDIs?

General Solution

Allow the window manager to manage documents. It is astronomically better than applications at doing this. Use sophisticated window management features like workspaces and shading to group and organize related tasks or projects.

Scribes Solution

As of version 0.3, Scribes implements what I call a document switcher. A document switcher is a window that allows you to focus any document open by Scribes. It is a scalable, efficient and effective alternative to tabs. You no longer have to worry about clicking on tabs or the taskbar to find whatever document you want to work with. The document switcher allows you to select the exact document you wish to work with and focus it. It doesn't matter if you have 3 or 20 documents open. The document switcher presents you with a scalable interface that allows you to search, sort and focus documents open by Scribes.

Old Habits Should Die

Some people have been so ingrained to using tabs that nothing will ever convince them of its irrelevance. For those people it is better to just use an editor that supports tabs. They are not in short supply. Editors that don't do tabs are the minority.