In the majority of cases that you communicate with journal editors you have to do it through a web form. When you submit a paper, or when you have to act on referee reports, or when you act as a reviewer of a paper. Science supporting agencies also have discovered the ease of web forms. Submission of proposals – usually in the form of filing out a number of text boxes and uploading a number of pdf files – also has to be done through a web interface.

The problem with web interfaces in an organization is that developing a user-friendly web interface is difficult, time consuming, and needs the involvement of professionals developers. The managers of the organizations that want to embark on using a web interface haven’t the least idea what is needed for a good interface and always find it too expensive. For the marketeers in the organization the web interface is yet another means of harassing clients, customers, or authors with unsolicited commercial promotion material. And the professional web developers are not allowed to communicate directly with the managers. As a result many mistakes are being made and the web forms arouse irritation.

In the rest of this I will present a, non-exhaustive, list of requirements of the web interface. You might have additional requirements.

Ajax
A professional web interface uses Ajax all the way. If not, the user is constantly confronted with disturbing reloading of web pages.

Browser compatibility
I like Google’s Chrome a lot because it is a lean product. Firefox has turned into a fat lady, constantly consuming all my computer resources even after I have closed it. Other people will have different tastes as far as their favorite browser is concerned. The web interface of the publisher or of the agency should state right away what browsers are supported and should issue a warning when the reader uses an unsupported browser.

Username and password
Username for logging in should be selectable by the user and not by the organization. A bad habit is to pre-populate the user profile with as username the email address of the user. This is terrible. Many scientists have more than one  email address, related to different organizations they are – or were – affiliated with. By using a clever forwarding and filtering system they keep their books. But the mobile scientist certainly cannot remember what email address they reported to which organization.

Manuscript status
For early-career scientists submission of a paper is an emotional experience. One hour after submission they check the journal’s web site to see if the manuscript has already been accepted. And any critical remark of a referee is felt by them as a personal insult. But basically all authors are curious to know about the status of the manuscript. A statement on the web site of a journal that “the manuscript is under consideration” , that never changes until the manuscript is finally accepted or rejected, is disappointing for all authors. In that respect the American Physical Society does a good job. The status of a manuscript under consideration is regularly updated with information like “waiting for report of second referee’. I notice that my junior coworkers like these updates a lot. They keep on telling me that the status has changed and tell me what the new status is.

Notification of changes
Many computer operating systems know the concept of an event handler. That is a facility to allow for asynchronous programming. You do not want to have to continuously poll a resource to see if there is a change. In case of a change the system fires an event and you as a programmer have connected this event to a program called an event handler.

But none of the web interfaces I know off have a notification systrem. That is to say my students have to continuously check the web site of the American Physical Socity to check whether or not the referee reports of their paper have been received by the editor. Even worse are organizations that request their users to continuously check the status as they will not tell their users that action on their side is necessary. Any web form interface should have a configurable system allowing the user to choose what events he wants to be informed of by email.

Access by co-authors
The same scientist can both be an author and a reviewer. So for the journal it makes sense to combine all these connected data and limit the outside access to the corresponding author. When this author logs in he can check the status of his submission. But he will also find there possible other active submissions and outstanding review jobs. This constitutes a problem to the corresponding author. His (junior) coauthors are keen to know how the review job is progressing. They even can learn from this process. But the corresponding author cannot give them access to the submission status, as he would have to give them his username/password combination that would give the co-authors access to all his review jobs and letters and likely access to all other private information as many people use the same username/password combination for other logins. The journal web site must also allow the possibility to view the manuscript status with an access code separate from the username/password combination of the corresponding author. For a web developer this is a piece of cake. And indeed quite a number of journals follow this procedure.

Spam and periodic email letters
If you have submitted something to such an organization for the first time they have your email address. And given the importance your submission is for your career, this address will always be a valid email address. Immediately after your first submission you notice you are automatically subscribed to a number of their commercial email activities. They tell you what other journals they publish and so on and what the recent speeches of their CEO were about. This is spam and as such illegal. But no scientist dares to complain to an organization that is so important for his career.

I think there should be an opt-in and never an opt-out policy. And if the organization is so arrogant to use an opt-out system it should be a one-click opt-out procedure. What is horrible is the following information: “If you do not want to receive this email letter anymore, please send us an email with unsubscribe in the subject” . I use five email addresses and I haven’t the faintest idea what email address of mine they used. In 90% of the cases it is in the bcc part of the email . Email clients like Outlook hide email addresses as much as they can. All this together makes it sometimes impossible to find out which if my email addresses they used. But even if I know the email address I have to send the unsubscribe request from that email address. This means making an unwieldy vpn connection and configuring my email program to be able to *send* email  from all my five email addresses. The best opt-out procedure is to supply the irritated user with a one-click url that contains all the necessary unsubscribe information.

Flat output
Sometimes when reviewing a paper and having written half of my report I want to consult a colleague. I do not want to give this colleague my login details. Or I want to check my earlier referee report(s). I hate to go to the web site and looking for the boxes where I put them and perform numerous copy-paste actions. I want always be able to get all my referee reports and all the replies by the authors in one flat (pdf) file.

My experience
This post was stimulated by several new web interfaces I was confronted with in the last couple of months. You must have similar experiences and additional tips for the organizations.

Follow