WriteFreely Improvements on Multi-user Mode (Part 1)
WriteFreely is such a beautiful software, that I feel lucky it was recommended to me when I was trying to find a suitable platform for write.c7.io. Yet, while it reaches perfection on presenting blogs and articles to visitors, its UI interaction logic in multi-user mode for blog authors (users) is kind of confusing.
I spend last couple days thinking and tinkering it to make it (in my opinion) much better. So I decided to write a series of blogs to document my rationale behind those changes. It would be two posts: what are the problems, and what have I changed.
Note: everything I wrote here is based on WriteFreely v0.15.
Part1: What I feel wrong about the UI interaction design.
The neat: Single-user mode
WriteFreely, reading from its code and template implementation, starts as a single-user program. It is pretty neat in single-user mode. There are fundamentally 3 pieces:
blog home It is the landing page of the website, and lists the contents of the blog, neat. You can login from there. Once you logged in, you are immediately brought to the editor. If you go back here, there is a mini menu that can guide to you both editor and settings / drafts.
editor As the name suggests, you can write your blog there and publish them. It also has an user menu on the top-left corner, it contains everything you can do as an author (change settings, log out).
settings / drafts It can help you config your blog, and change account info. Note that account name doesn’t really matter in this mode. There is also a drafts page which, ties to this settings panel tightly. You fill find why later.
The navigation between these pieces are pretty straightforward. You write posts, publish them to either blog or drafts, and go to settings section to customize.
The ugly: Multi-user mode
Things get messy here. In this mode, each author are allowed to have multiple blogs. So there comes 4 pieces:
site home It is the new landing section of the site, and contains multiple customizable pages like About, Contact etc., which can be considered as site level contents. And there is a reader page lists recent public posts of the whole site. Great! However, once you are logged in, visiting the root of the site (i.e. https://site-url/) no longer brings you here, but the editor! Note that there are many places leads to the website root, like site name in footer, and clicking them all leads to the editor.
blog home It is the same blog home in the single-user mode. And now it has an address of https://site-url/blog-name. It has the very same mini menu for logged in authors. And the very first entry in the menu, while prints site name on it, brings you to the editor because it has an url of site root.
editor There is a new top-left corner button that brings you to the blogs page, which is part of the settings section. And on the right, the button to the left of the publish no longer brings you to the blog home (because you may have multiple blogs), but to your drafts.
settings / blogs / drafts Since you may be allowed to create and manage multiple blogs, there is a new blogs page here. And this is the only place you can visit certain blog home unless you go to the site level reader page and find yours among others. One confusing part is, that the address of your very first blog will always be https://site-url/user-name/. And you can never delete this blog. You can have customized blog url starting blog #2. Confusingly, the site-level reader link is shown here. And despite you may have multiple blogs, you would only have 1 shared draft box. The drafts page is logically attached to your account, not any blog, that is why it can be considered an “account setting” per se.
So in multi-user mode, for visitors, it has a interaction hierarchy of site – blogs. Neat. For logged in authors, it becomes site – settings (blogs) – each blog, except the site url is now the editor, and the editor points back to the settings section.
There are couple problem in my opinion:
It is extremely annoying to open the editor when an author clicks the site names, which are everywhere. Especially the editor in this mode no longer functions as a good navigator because you may have multiple blogs. Moreover, it present different content for authors before/after login, at the site root url, destroying author’s previously established navigation habit. Come on, there are more than enough New Post button that can do the job! I think all site pages, including the landing page, should be static for everyone. In single-user mode, there is simply an additional menu after login, and from there author can exercise their privileges. The multi-user mode should do the same.
The editor no longer associates with a blog, because you may have multiple blogs. However for any blog writer, the intuition is I shall be writing for a blog, not an author account. It is confusing to only have buttons reaching back to the blog list / draft / account settings page, despite it allows you to choose the target blog to publish. The blog configuration pages has the same problem though less confusing. I believe the ideal workflow should again be same with the single-user mode. Author should see the blog first, then open the editor to write for it. Conceptually the editor should be under the blog in the interaction hierarchy. And similarly, the blog settings should be arranged under each blog as well.
The editor also function as a nav component. While in single-user mode it sort of worked. It creates anxiety if author want to navigate away with unfinished content. Will they be saved? I think an editor should just be responsible for editing. The only way to exit is publish/save or discard. Since I already discussed that the editor should be a sub layer of each blog, it doesn't have to handle any nav functionalities. (Yes, editor does save your unfinished, unsaved article in your browser's local storage).
The very first blog uses your account name, while others don’t. It unnecessarily couples username and blog names, so when an author changes their user name, the url of the first blog changes. Confusing. It would be much simpler from both programmer’s and user’s perspective, to totally separate account system and blogs system.
Ideally, the site interaction hierarchy for an author should be, site – account admin and blogs addition/deletion – each blog – editor/settings. The site layer should be static and not to be associated with the editor. The account admin and blogs admin can be in the same place but not programmatically linked. This would make the whole site very navigable for authors. It would also be great of each blog can have their own draft box but a shared draft box works okay as well.
In case if the site only allows 1 blog per author, like write.c7.io, the account/blogs management layer could simply be eliminated, and the account management can be merged into the site menu. This mimics the good, simple single-user experience.
Ok, I think I should stop here. I will document what exactly I changed to make WriteFreely fit in the next part.
ps. There are several configurations that is relevant, and I played with almost all combinations, but nothing really make things better:
- The new “chorus” mode is half-broken. And it is intended to melt the site and all blogs together. I don’t recommend it.
- “Disabling drafts” don’t really disables it. It just hid a few “Drafts” link. You can still send your post to draft and takes a while to find them again. This could potentially be a bug in the editor but nevertheless shared draft box is better than no draft box.
- There is a “SimpleNav” mode, whereas no documentation can be found. It looked half-baked as well, so I gave up.
You can reach out to me at [email protected], or via Mastodon.