Basic features

This actions should be accessible from every part of our account interface because they are the most important.

  • Write an article;
  • Go to the account settings;
  • Go to the articles management page;
  • Go to the tags and rules management page;
  • Go to the moderation page;
  • Go to the journals management page;
  • Log out.

The one way to implement this is a simple tabbed interface on the top of each page:

What can you get from this interface?

  • You are logged in as user "simanyay";
  • You can log out if needed;
  • You are in the journals management section;
  • You can start new article;
  • You can go to the articles management section;
  • There are 4 articles that should be moderated;
  • You can go to the articles moderation section;
  • You can go to your settings.

I think that we should take Google's approach to coloring different sections with different because it helps to identify different sections (our eyes divide colors much faster than words). And also, (this is important!) we should not remove underlines from links because this helps to identify links from other content.

However, we should also use iGoogle approach but not everywhere. The most optimal place for it is Account's frontpage. We should put there aggregated draggable boxes that will show interesting information for the user. For example, one box may list new unapproved articles (titles), another box new comments, another some notes, etc. Some boxes will be read-only i. e. there will be a list with links pointing to the appropriate section of the account subsystem. Other boxes should be active: for example, notes box should allow user to add quick notes, comments box should allow user to delete spam comments (we can say that comment is a spam if it starts with viagra or something).

Articles management

Here, a user will review and edit his own articles (no moderation here), so, I guess, the best solution is GMail like list with a checkbox and two links for each item (an article, in our case): edit this article and view it on the website (with webmore and stuff).

In this section a user should be able to:

  • Edit articles;
  • Delete articles;
  • Go to the webmored version;
  • Hide article (we don't want our draft to be in the pool);

There also should be a search box in order to allow users to find their articles by title, text or tags.

Tags and rules management

This section should allow users to:

  • rename tags;
  • delete tags;
  • create rules;
  • edit rules;
  • delete rules;

Such actions like add tag, delete all articles by tag, etc. should be in the articles management section. The interface should be pretty simple with console in mind, because it is much faster to type "alapos" to one text box and "thiblo" to another and click "rename" than selecting the tag from the hundreds of others and then dragging it somewhere.

However, here and in articles management section we should implement autocomplete like in

We should also keep in mind that users often misspell tags (I am one of such users, for example) so we after the release we can think about some nice feature that will look for almost identical tags and show some hint like "hey, these two tags is almost the same, combine them?".

Journals management

I believe that we should not let users to easily create their own pages. With that approach we will get a log of badly designed journals (just look on the old free html hosting web sites like or Instead, we should give them a set of ready journal structures and let them to choose some colors and fill the boxes. These journals should be like: simple blog, community, political journal and so on. Designer should do the design and not the users (design, as you know, is not just colors or something; it is how information presented).

So, in the journals management section user will see his own journals as boxes with some statistical data in it. He then can click on the appropriate journal and change its structure (by selecting a template) or change some colors or fill out the blocks.

However, we should allow more competent users to create their own structures by writing a special XML file.


<!-- ... -->
<block name="header" type="vertical" width="100%" height="25%">
  <block type="horizontal" name="logo" width="250px">
    <!-- ... -->
<!-- ... -->

Another way is to allow them to write XHTML but with special ids:

<div id="thiblo:users"></div>

And then, in the journal structure editor they will be able to create a block named "users" and fill it with some information.

We should also create a small action that will allow users to duplicate some journal. As an input data it will take journal's URL or a user will find it by the name. Clean and simple.

Preferences (Settings)

Preferences (Settings) should be a simple page with various options like:

  • Allow/prohibit comments;
  • Change email address;
  • Change password;
  • Delete account (very important, users should be able to delete accounts);
  • etc.

Articles moderation

I believe that we should allow user to get a cup of tea and scroll and aprove and deny articles with just one finger. So I propose to make a GReader like interface where we will display an articles awaiting moderation and user will scroll and click on buttons.

However, I think we should not display full article without a special request. Just a title, authors name, abstract and links: read more, aprove, deny.

Comments moderation

I think that comments should be moderated "on page" i. e. on the actual webmored page because it is impossible to remember the whole thread and decide if this comment is offtopic or a good one. And there will be aproved comments and grey, to be moderated comments.

One click: delete or show.


User should select what notification letters he wants to receive and we should simply send them after each action, if needed. I don't see a problem here.

However, I am totally against the LJ's messaging system. In case you don't know, livejournal sends notifications via the email and also has its own messages center. And every user I know read the notification message in their mailbox and then manually delete it from the message center. It is boring and annoying.

Important UI features

Delete nothing

Confirmation messages are meaningless because clicking "OK" after an operation that requires confirmation becomes a habit to the point where you don't read the dialog at all, and your fingers/mouse click OK without engaging your brain. I believe we should go GMail way where we will allow users to delete/deny/hide any objects and we will provide an undo action for each of them.

Save states

I believe that our application should save user states. So if he was in the "Journal management" section, then he should return to it after the next log in. This should be like hibernate but for web applications. So, if somebody starts an article and then quits (network problems or he had to run to pick up his child from the school) after the next login he should start not with a start page but with that article draft.


Google Web Toolkit allows us to integrate our interfaces with JUnit and we should not ignore that. All interfaces (not proof-of-concepts, of course) should be tested with JUnit, no commit should be done if there are failed test cases.


I believe that the first working version can be implemented in 2--2,5 months by two developers. However, reducing the number of developers to one will not increase time to four months. I think that one developer will be able to complete the first version in 3--3,5 months (with the help of GWT, of course). I also think that we should try to do one-week sprints only.

Here is the plan without estimations just to set up priorities:

  • Articles management section;
  • Tags and rules section;
  • Articles moderation section;
  • Comments moderation section;
  • Account settings;
  • Journals management section;
  • Personal settings and authentication;
  • iThiblo.

We can actually show the first closed beta at WWDC in August. :-)