4

I'm working on a web application that allows product owners to publish content across various devices. Publishing is not instantaneous and I must inform product owners that this process can take time along with a status. In my model, product owners publish content from "Available Content" (unpublished) to "Publish History" (status + history).

User Stories

  • I want the ability to view unpublished content.
  • I want the ability to publish content.
  • I want to understand the status (e.g., in progress, done, etc.) of content I've published.
  • I want to view a history of content that has been published.

User Flow Product User Flow

Questions

  • When is it appropriate to tell users that "this may take time"? I plan on displaying a confirmation modal with their list of content and a message. FYI: There is no way to show an exact completion time, but a range is possible.
  • Does it make sense to move "in progress" items to a "Publish History" tab?
  • It is really two separate concepts? A history AND a queue? Product owners need the ability to view that status of items along history of publications.
12
+50

Here's what I think regarding your questions, one by one.

1- When is it appropriate to tell users that "this may take time"? I plan on displaying a confirmation modal with their list of content and a message. FYI: There is no way to show an exact completion time, but a range is possible.

A good analogy is to think about it is to imagine the product owner as the manager, and the system as his assistant doing what he asks.

Now using this analogy, would it be OK for the assistant to receive a batch of work to publish, get out of the door, then come right back and tell the manager: "This will take time. Are you sure you want to publish all of them? Please confirm and I'll do it". Being new to this company and not knowing about the practice the first time, the manager would say something like "Uhh, ohh, yes, please do it.".

Next time around, the assistant takes the work, goes to the door, comes right back and ask the same question: "It takes time. Are you sure?". The response would be something like: "Oh yeah, I know. But just do it please.". A month passes, the assistant is still very consistent in his practice of asking for confirmation. The only difference is the manager is getting increasingly annoyed. And I guess you already see how it'd go. I bet his answer in the 2nd month would be something to the effect of "JUST ... OFF AND DO YOUR JOB. DON'T NEVER EVER ASK ME THAT STUPID QUESTION AGAIN."

Having a confirmation modal is (in most cases) NOT an appropriate way to INFORM users about something. Potential solutions?

  • a) Having the message placed somewhere right on the page (before product owners actually choose content and press Publish). It'd say something like "Publish content may take time. You can however check the progress by checking the content's status here."

  • b) Having the message displayed on Tooltip/Popover when product owners hover on Publish button.

  • c) Having the message appear right under the Publish button when they click, AND an option to NOT display this same message the next time. A slidedown/collapse expanse component might come on here to add some visual effects and gain users attention.

2- Does it make sense to move "in progress" items to a "Publish History" tab? Depends on how your product owners understand the concept "History". But semantically speaking, no, it does NOT make sense. But see question 3 for more ideas.

3- It is really two separate concepts? A history AND a queue? Product owners need the ability to view that status of items along history of publications.

What we are having here is actually 3 stages that the content has to go through: 1) unpublished, 2) staging/publishing/being published, 3) published.

The history should ideally be used for the 3rd state. The queue is for 2nd state. And the current tab Available is for 1st state. This analysis implies that the current design lacks an explicit list dedicated to display the 2nd state.

Potential solutions:

  • a) Add another tab in between Available and History. What is not published yet will go here with its status/progress. Only what is already published will go to History tab.
  • b) Abandon the Tabbing concept, go for Filtering. In other words, having all content in one list, accompanied by their status (To publish, Publishing/BeingPublished, Published). There would be a filter on top of the list with options to let users narrow down to the set of content they are most interested in. The good thing about this solution is that it gives users a full view of all content, but give them the flexibility when they need them. Moreover, it maintains the context of the items (after users press Publish button, the items stay where they were before in the list. Now they just need to have another label on the right that says "Publishing" - and probably the notification "It may take time" on mouse hover to re-inforce and remind users about the delay constraint.)

Some notes:

  • How do you think product owners would cancel their in-progress publishing? Can they do it? If you think they should, then having a Stop publishing button next to the in-progress items would be helpful. It would bring the content back to To-publish state.
  • As you see in my sketch, I use "To publish" to describe the current "Available" state. Easier to understand label.
  • I keep your idea of using the checkbox to the left of the item in my sketch. However, an alternate option is to put a LinkButton inside the list, right under its status (similar to the LinkButton Stop Publishing).

Hope it helps. Below is my quick sketch.

All content

To publish

Being published

  • Product owners CAN NOT cancel something that is in progress. This also made me think of a confirmation modal because it states that a) you are publishing content that will be seen by consumers b) this process takes time and c) this process CAN NOT be canceled. – erik_lev Jun 22 '14 at 21:41
  • 1
    OK I see. However, it's almost always a good idea to let them "Stop publishing" or "Unpublish". Can I ask for the reason behind the CANNOT decision? What if they make a mistake? About confirmation modal, I'm pretty convinced that the Product owners won't read the msg after some time, and just press Close the modal as soon as they see it. Mistakes will still occur. – Son Do Lenh Jun 22 '14 at 22:07
  • Technical reasons and a short timeline. It has something to do with how the content gets "pushed" to the CDN. – erik_lev Jun 22 '14 at 22:54
  • A low-level critique, but I think 'draft' is better copy than 'To publish'; it's more brief, to the point, but more importantly very widely used in other apps when you have something that you may publish, but has yet been. – Andrew Gray Jun 26 '14 at 18:04
  • FWIW, those "filters" are totally still tabs. – heathenJesus Jun 27 '14 at 22:27
3

You have to work on your terminology. Good terminology helps to build the users mental model.

"In progress": it can't get any more vague :-). What is happening here? Why does it take time? Is being uploaded, reviewed, pushed to all devices, ...? Find a better name and maybe you have to explain less.

"available": available to whom? Publishing is also making it more available. How about "Ready"?

"History": from your descriptions, it seems like the user wants to know the current state, and not some information about past states. So "history" is not such a good choice. How about "Publications" or "Published"?

Now back to your questions. You basically have items (articles?) traveling through a few states (??>Available>in progress>Done). Visualizing state by removing the item from one list and adding it to another would only be a good idea if you can visualize both lists simultaneously. It gets confusing to the user if his data is always somewhere else.

You could consider a single list that also indicates the state.

  • Agreed, the terminology isn't perfect and thanks for the information. – erik_lev Jun 22 '14 at 22:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.