Scribz.net™ Blog

Once I was sure that it was feasible for me to build my own online notepad, I was wondering where to start – do I begin with the architecture of the application, or do I start with the visuals and layout?

To be frank, this wasn’t as straightforward a decision as one would hope.

Normally, starting with the information workflow and application structure is the best idea.  Granted that you know exactly what you are going to produce, of course.

In this case, I decided to take the artist’s approach to the task; some may call it behavioral.  Scribz.net™ was going to be a very simple application after all (at least initially) so I figured that starting with the visuals might help me decide which features I would want to include and in what order.  I thought that I could devise my application structure based on the logic of the usability.  I was sure I could code (implement) almost anything related to this application, so I felt that a reversed approach might be justified this time.  How cool that the simplicity and power of Scribz.net™ was already proving at such an early stage!

Thinking Visually

Drawing different mock-ups of the visuals was quite fun.  I ended up with several napkins and torn college block pages scribbled all around with notes, random arrows, and tiny bits of explanations.  I did most of my drawing by hand, with virtually no computer help.  I though I should mention that.

I played around with the locations of the menus, the control buttons and, most importantly, the location and format of the note list.  (Even though I had not implemented the note list until a while later, I did have the idea on the table from the beginning.)  It was interesting to think about utility from the position of the service provider for once.  It is easy to get upset with others’ sites, so I aimed to make my users happy with Scribz.net™, especially as I was going to be one of them.  As always, I wanted to make the interface pragmatic, intuitive, and easy to use.  So which considerations did I make?

1. I wanted to make a scalable interface which would easily adapt to mobile browsers and would render well in as many browsers as possible.  Almost any screen resolution should accommodate for the entire editing interface.  To achieve this, I intended to use CSS and write the HTML markup as simple as possible.  Also, images were outlawed.  Maybe in the future with more resources and talent – but usability is always first.
2. In addition to clean markup, the page had to render and function with all features without JavaScript or any similar trickery.  The only fancier technique should be post-back, which is kind of inevitable.
3. I wanted to make it easy for everyone to edit her or his Scribz™, with as little clutter as possible and with straightforward commands.  The resulting editing interface was supposed to be lightweight, fast to load, accessible, and well laid out.  This also meant that the entire experience was to be limited to just one page.  I did not want people to have to click on a Scrib™ and then edit it on another page, and then get back to the original list, or some such.  That is one of the reasons why I despise of bookmarking services.  In the worst case, they are extremely ugly and cheap-looking, with multiple pages and forms you have to go through before you can complete an entry, let alone editing anything.  In the best case, they are powered by AJAX and similar Web 2.0 technologies and hence fail to work in older browsers and mobile browsers.
4. Speaking of positioning, all menus and buttons must be placed in such an order that they are hard to mis-click or even miss in general.  There is nothing worse than trying to save your complicated, inspired idea or text and hitting the "Revert Changes" button instead.  This called for clear labels and large landing areas for all controls, which also meant that most <a href=""> elements be formatted as display:block; (CSS notation) and occupy enough screen real estate for people to be able to just use them conveniently.
5. All visual elements were to have a clear meaning, command text and (in some cases) tool-tip.  This went in hand with the button positioning and the layout of the page.  The list of Scribz™ especially had to be easily legible for the human eye.  Only the necessary information was to be shown in it.  This is also the reason why I dropped the display of created date in the Scrib™ list.  This piece of information is still stored with each Scrib™, but only last modified alias edited is shown to users.  The created date was intended for sorting and filtering purposes.  Lastly, excerpts are a very useful feature, but should be optional.
6. I anticipated that I’d go for keyboard shortcuts pretty early on – it is just so natural to hit Ctrl+S that this functionality was imperative for creating the feel of a real application.  Personally, I think that the need for good keyboard shortcuts in web applications is extremely underrated and this is to the detriment of all parties.  I know what you’re saying – it is JavaScript which lets one intercept key presses in a web browser.  But the page would work just fine without shortcuts and so I was not violating  my "tenet No.1".  Good point though!  (The above link was a great place to start learning about keyboard automation and JavaScript.)
7. In the end, the page should render relatively well even if style sheets were not available.  This is a general rule of thumb for determining whether a page is designed well.  Firstly, it ensures that the application is usable (although ugly) at all times and it also means that it can probably be very easily themed for mobile browsers, for printing, or for any other type of media.

In Hindsight

Looking back at the initial design, there were definitely some things I missed or overlooked.

One thing I did not consider – and I should have – was to make the site as flexible and fluid as possible.

For a couple of months, Scribz.net™ did not scale to the width of one’s browser, which I realized was but a waste of space on the screen.  While it is common for web pages all over the web to operate in fixed width, I think that in many cases this is actually bad practice.  The web is a flexible medium and the markup allows for many fun uses of the fact that a browser window scales.  Read the most entertaining article (and demonstration) I know on the so-called fluid or liquid web layout.

Now, however, the entire interface scales to whatever width you adjust it to, with a pre-set "reasonable" minimum and dynamically calculated widths of the main elements.  All pure CSS, just so you know.

So once I was relatively happy with the visuals and the layout, I proceeded to plan the internal workings of Scribz.net™.