I just read this blog post by Sascha Lobo. Admittedly, it's from 2011, but it reminds me of a question I asked myself again and again when writing websites. That is, the technical sides thereof, not the contents. The question is how to enable users to enter information.
Backends
The traditional way to do so is to have a backend to your website. Say, you have a dedicated space, where you can change settings, enter information and edit the website as much as the programmer allowed you to do.
There is one major downside to having a backend: it's a dedicated space, separate from the frontend, where the information is later presented. If you are, to give an example, just browsing your site/service, and you want to enter information, you need to open a different URL. That is one extra step, and any additional step is a major roadblock.
The upside of having a backend on the other hand is that there is space for more functions. Drafting or editing without a backend is surely possible, but whatever alternative interface you have might get cramped easily and thus get hard to use. With a dedicated space for adding or editing your posts, you have the space to add radio buttons, additional input fields or whatever at more convenient places without the page getting overly cramped.
The preliminary answer to when writing a dedicated backend for adding/editing information on your site is appropriate may thus be: if you have many options, use a backend. If the user should only quickly write things and then post them, the posting interface can be placed elsewhere.
Alternatives
There are several alternatives to having a dedicated web-based backend for editing your website. The first is to move the whole thing offline. A popular example for that may be static page generators - even if they remove publishing so much from the place of publication that this solution, too, might make the user post less.
A second alternative is to embed the posting interface right into the frontend for logged in users with the respective rights. This is what Facebook did. It's what Twitter did. It's what Sascha Lobo did, too. Unfortunately, it also means that the user will be much restricted in their options. Ease of use beats flexibility (That the most popular sites for posting content on the WWW, e.g. Facebook and Twitter, use this approach should be proof enough of its effectivity).
A third alternative would be offline clients that connect to your website/service and already know your credentials, so that the additional step of logging in is removed. The miriad of Twitter clients is just one example of this. Again, any additional step to posting is a roadblock that should be overcome if ever possible.
What I Want
I am an avid defender of giving users options, and doing so as straight forward as possible as long as it does not drive them away. E.g., while I syndicate my notes to Twitter, I have an option in the backend of my website to not do so for specific posts. Similarly, there is an option to turn notes into likes. Two additional options make the interface more complicated than, say, that of Twitter. For new users who might want to use the CMS I wrote to run this site on, this might be irritating (more on that later).
Restricting the user is bad. On the other hand, giving them too many options turns users down. Clearly, there is a difference in interest here. My idealistic hopes clash with users' wish for convenience.
Analyze What You Are Working on
Indeed, sometimes making things as simple as possible while giving up on the idealistic wish to enable the user to decide as much as they might ever want is necessary. Whether it is is decided by what one is working on.
As I see it currently, there are three major factors at play here:
- Target audience/potential users
- Use case
- Additional factors contributing to the likelihood of use
While these aspects apply to essentially everything, they also apply to how complex you can make your site, I think.
If your target audience is more specifically interested into a certain cause and shares a common interest in being able to have a certain option, then adding that option will be less of a roadblock. On the other hand, adding options that your possible users are unlikely to understand will, if anything, be irritating. While this problem might be avoided a bit by placing the option in question in a less prominent place (if one were to introduce a backend), this will only lead to quantitative changes. Additional options still mean a potential roadblock.
The use case is kind of similar to the target audience. What are your potential users going to use your site/service for? If it's Twitter, the main interest of users will likely be to send out their message as quickly as possible. Any additional option that the user needed to consider would be too much. On the other hand, if you have a complex system like museum-digital for indexing and presenting information on museum objects, having a large number of options will be necessary.
"Additional factors contributing to the likelihood of use" refers to about anything else. If you have the network effect on your side, you might be more liberal in choosing to add additional options.
What Does That Mean to Me?
In this last part, I will outline my experiences with the three main web programming projects I am involved with in my free time (sometimes paid, too). The first two are strictly hobby projects: JACMS, the content management system this website runs on, also powers ppanji.org. I was thus able to get feedback on it and the approach to editing data I used in it. JACMS has a backend, but recently I wrote additional clients for posting at least notes.
Second, there is Aklaman. Aklaman is a tool that takes existing bibliographical databases from multiple users, merges them to let the users profit from each other's work, and let's them note down additional data like quotes for each work in the combined database. More and more, the "projects" feature of Aklaman also became important. Using this, users can associate texts to a topic/project, associate citations from these to the project, create a project blog, and link content from around the web to the project. Aklaman mostly uses the "just wrote on the web" approach. Backend and frontend are not distinguished.
Finally, I have found myself spending about a month per year on improving the code of museum-digital. As noted above, museums can index and present information about their museum objects using museum-digital. As there are many, many aspects of these that can and should be described, say, as there is a need for a multitude of input options, museum-digital relies solely its rather complex backend for adding and editing information.
JACMS
One of my main reasons for programming JACMS was my unhappiness with the restrictedness of the usual alternatives like Wordpress. Back then, I was strongly inspired by the Indieweb crowd with their differentiation of different kinds of posts - articles (full blog posts), notes, bookmarks, events, etc. I implemented most of those and added my own, publications and presentations.
This multitude of different kinds of posts of course made the whole project more complex. Adding additional, then again mostly Indieweb-inspired, options like syndication added to this complexity. Writing a backend was thus not only the first thing to come to mind out of being used to them, but also the logical thing to do.
On the other hand, I was thinking about how I could get at least myself to use it more. For those kinds of posts that are less heavy on options, I thus also implemented the "just write on the web" approach. I need to admit that I was a bit lazy in doing so: I just embedded the page for adding notes (and bookmarks, and so on) from the backend in an iframe for logged in users. That I never took care of designing this embedded version speaks for itself. I don't use this function.
Seeing how I only rarely posted notes from the backend and as good as never used the option to post from the website's frontend, I decided to write clients for posting directly from my PC without logging in (better, the credentials are in a separate file and automatically send with the content). This approach was successful in getting me to post much more.
My client offers two ways of being used. First, users can open the GUI version, that also offers additional functionality like automatically logging in to multiple sites. Again, I don't use this, as opening the program is one step too many.
On the other hand, I use the same code to post directly from the terminal. Since I have a terminal open most of the time anyway, I can thus avoid any additional steps. And indeed, I do post more now. Thanks to an alias, I post notes by simply writing post-note "Whatever I want to post". This however only works by settings defaults and taking away the options I'd have given myself by posting using any of the alternatives.
On the other hand, more complex kinds of entries, like blog posts or events, are something I still enter from the standard web-based backend. I want to have full control of the different options and writing a blog post is more than a little work anyway. If I already put up so much effort to get it written, adding logging in and opening a web page for posting are not too much additional effort to ask for.
Aklaman
Aklaman requires all users who want to enter information to be logged in, simply for attribution of their additions. It was thus logical for me to combine posting and reading. If a user wants to add information, they simply click a button and forms for posting appear where the content to be posted will appear later. Alternatively, if something is to be edited, the content gets placed into a form for changing it at the same place where it had been presented read-only before.
Only some information demand specific pages dedicated for editing them. These are first of all page settings - e.g. when users want to use a custom page design - and user information - so that the user can be more easily approached by potential other users. Also, there is a dedicated page for "tools", on which users can upload their bibliographical databases.
I previously convinced the lecturer of a course at my university to use Aklaman for gathering information from the course at a central place. Her original alternative was Zotero, on which she would have wanted all the reviews etc. to be uploaded as annotations to the bibliographical entries in a shared list.
While Zotero is a great program, Aklaman seemed much more apt for doing what she wanted to be done. It has a function specifically programmed for the same thing she wanted to be accomplished, while Zotero would have to be used beyond its original purpose.
In the end, the response to Aklaman was existent but low. About half the students ended up using it, while others were complaining about there being too many options. My lecturer subsequently decided to try out Zotero instead. I was the only one to at least transfer the information I had collected on Aklaman to the Zotero list.
This is where the third aspect I mentioned above comes in: other pull factors. If you have a group of unmotivated users that do not want to explore your program (be it Aklaman or Zotero), they will not do so. And if they are forced to look at it, they'll do so as swiftly as they can.
By the way, in this case even extensive documentation and howtos didn't help. Zotero has those anyway. For Aklaman, I have my (outdated) documentation page and I also wrote very picture-heavy howtos. As a bit of promotion, please excuse me linking the code of Aklaman, which is open-source.
museum-digital
museum-digital is a project of a growing number of museums to present their objects online (later, indexing object information was added as a purpose). Thus, there is already a given user base (the museums) that have an interest in the success of the project and will stay with it. The use case demands a lot of information being put in for each object. While a number of checks have been added to drive users to deliver high-quality object information, driving them to do so at all is a relatively minor question in comparison to my experiences with giving Aklaman to a university course.
The high number of different kinds of information to be added, demands a backend. While backend design eventually became a backend, there are few complaints.
museum-digital is thus a good example for when it is appropriate to have a complex (and in this case really much so) backend:
- when users have a high interest in having so many options,
- when they are a rather homogenous group that understand the meaning of most input fields/options because of their knowledge of the field,
- when the data to be entered is complex and different kinds of information need to be differentiated from each other clearly.
To Sum Up
To sum up, it's all dependent on the context once again. Depending on what kind of website/service it is, having a backend or not might be advisable. Implementing different options to post is a nice way to try out which one works best. If one does not have the time or ressources to do so, it's most important to look at what the aim of the users are and to choose the most appropriate option based on that. Simplicity is not always the answer, but if users (and in most cases, that's mostly the one programming things themselves) can't be made to use the website/service due to other factors, then it might be preferable. If there are however other pull factors and an aim that demands differentiated and complex information to be put in, keeping the complexity (and thus adding a web-based backend as the input method of choice) might be preferable.