Talk:OJS Dashboard

From PKP Wiki
Jump to: navigation, search

Bruno's new screenshots

  • About category rows...
    • What categories are we proposing? I currently see...
      • Unassigned
      • My Assigned
      • My Authored
      • Active [this will be confusing, as entries in any of the above 3 can also be considered "active"]
    • Are there others, and how do we handle items potentially appearing in several categories?
    • Will this be confusing for users who have just a single category, e.g. reviewers?
  • The key motivation for the dashboard was to provide an answer to the question "What do I need to do?" at a glance. Does this answer that question?
  • Would the "Archive" still exist as a separate tab, and would it be affected by the changes proposed here?
  • Just to confirm -- does this mean we're making the dashboard fully context (e.g. journal) specific, and that there will be no more global dashboard?
  • What about tasks that don't belong to a particular submission? OTOH we don't have any of these, but it was discussed.

--Alec (talk) 16:10, 7 May 2014 (PDT)

  • Active is anything that's being under editorial process that doesn't fits the above categories.
  • Item should only appear in one category. I don't see need for more categories.
  • Categories should not appear if they have no items, so reviewers will not see them all.
  • I think that's why we need to keep the tasks tab (see at a glance what we have to do).
  • Archive should exist, but I don't see the need to show tasks there.
  • Dashboard should still be global. I still think it's good to have a checkbox to enable it, and as soon it is enabled, users can interact with context filters for the grids (both tasks and submissions).
  • That's another reason I don't think it's good to remove the tasks tab.

--Beghelli (talk) 18:30, 7 May 2014 (PDT)

Agree with above, although we need to experiment with task tab. Further on the icon discussion, we do want the eye to go to the tasks so I'm ready to think about icons for this. For the editor, we may want to just bell their tasks, while indicating that their section editors have tasks outstanding on their submissions but without requiring the same level of attention. The Unassigned needs no additional attention, as every item there needs the same thing every time one appears.

In that sense, I ask you to look again at this screen shot and ask yourself whether a red bell with the number 1 or 2 in it is needed to draw your attention to the presence of a task, compared to the current use of asterisks indicating a task. I am not arguing for the asterisk but only for using no more of an icon than is needed in scanning a list (and thus am not yet entirely an iconoclast). We need to think of this as a list that the eye scans down checking where things are at and what needs to be done. Google uses the bell to bring your to a part of the screen you are not otherwise considering; this is a dashboard and what you are checking is the status of tasks.

--Jwillinsky (talk) 23:41, 7 May 2014 (PDT)

The global vs. context-specific nature of the dashboard bleeds into the global navigation discussion. This specifically caused a lot of the global navigation confusion...

  • It's the only exception to "global nav goes on the very top navbar" (journals pulldown, administration link, user profile link...)
  • It potentially presents the contents of one journal styled in the format of another

I liked the proposal at http://pkp.sfu.ca/wiki/index.php?title=Dashboard_submission_lists to make the dashboard context-specific by default, but allow the filtering tools to extend to other contexts at the user's choice.

John, I thought your proposal was a replacement for both submissions and tasks tabs. I don't have a strong opinion either way, but we are trying to avoid presenting the same content in multiple places as a general rule.

Bruno, for reviewers who have a single submission (a common case), this will look like...

  • Submissions
    • Active
      • My Submission Title

--Alec (talk) 10:52, 8 May 2014 (PDT)


Notes from May 9, 2014 PKP UX Meeting

We need prototypes or wireframes to test the following issues:

  • title vs id linking in submission list
  • john's ui element suggestions for dashboard
  • tasks - 2 scenarios (without tasks separate, tasks embedded in submissions list)


--Kstranac (talk) 7:57, 9 May 2014 (PDT)


Comments related to recommendation I

  • About more info light modal:

More info John.png

Notes: I’d love to just see what rounded corners would be like. I’d like to add “and” to before the last author, as it assures the reader that all authors are listed.


  • About tabs:

Tabs John.png

Notes: Your rounded corners on the tabs are needed here. The spacing of the tabs may need work and have to respond to size of (number). “Current” is better than “Future” issues for the mega-journals; and ISSUES may need to be VOLUMES for mega-journals.


  • About editor hover:

Hover John.png


  • About archives and delete submission action:

Archives John.png

Notes: I couldn’t get the button lined up or create a standard button.

--Jwillinsky (talk) 22:00, 19 May 2014 (PDT)


I liked last suggestions by John. Only 3 things:

  • I do not agree on keeping the action "start new submission" and the search at the top, next to the tabs. Before we had issues, it made sense, the whole dashboard was handling submissions. Now it doesn't. The search tool would have to work for both submissions and issues, and all 4 tabs would have to update their content when user searchs for something. I think it is more efficient now to use the grid search, and solve the problem of users not finding submissions as I proposed in recommendation I.

The action start a new submission is also out of context now. Specially because in issues we also have create an new issue action. Why submissions is up there and issues aren't? Users may get confused by that. Since we are using the dashboard for more objects than submissions, I prefer to keep every action in context now, I think it will be easier for users to understand.

  • I like the way of deleting submissions in archive, but the action delete should be on the right side of the grid, as a grid action. For that to work on submissions, we would have to introduce actions inside the category grid row, which I think it's ok.
  • The hover is not a design choice, it is controlled by the browser, and black and white is how firefox handle it. I think we can style that in someway, but not sure if we want to introduce more code to change that. I am happy to let the default style.

I've updated the wireframes to make adapt the submission more info light modal and to update the delete submission action. You might need to refresh the page using SHIFT + F5 to see the last files.

--Beghelli (talk) 04:09, 20 June 2014 (PDT)


Revised Dashboard Tab Labeling and Placement of START NEW SUBMISSION Screen Shot 2014-06-20 at 9.50.11 AM.png --Jwillinsky (talk) 09:54, 20 June 2014 (PDT)


I think we have two functional options for search:

  • grid level: the search controls should be inside each grid, each one showing it's own result without influencing the others. To partially solve the problem that users might not find a submission that's archived or active, we can add a message when the search result is empty, saying that users can try the same search on the other tab (active will search for archives, and vice versa). To completely solve the problem of not finding submissions, we should add this "search on the other tab" for every search, even if it shows results. This could be a link inside the search controls.
  • dashboard level: the search controls should be at the top of the tabs, with the search icon at the same horizontal line of the tabs. This should work for all tabs. We can add a control so users could tell if they are searching for submissions or issues.

Placing the search controls in a dashboard level but without the possibility to search for all dashboard elements is not good, I think. Let's say we don't allow search for issues, but the search icon will still be up there while users are visualizing the issue tab. Clicking there and waiting to search for issues will be a very common step for users. Then, after clicking and experimenting, they might get confused and frustrated it was not working the way they expected.

--Beghelli (talk) 10:00, 20 June 2014 (PDT)

agreed -- and I'm for grid-level search across the four tabs, indicating finds in each, as per your idea. Some redundancy in results but options in locating the work in different contexts, in an issue or as as submission. --Jwillinsky (talk) 10:39, 20 June 2014 (PDT)


Still related with Screen_Shot_2014-06-20_at_9.50.11_AM.png image:

  • For users that are more than authors, Start a new submission link action will not be so much visible, because there will be potentially other grid categories before My Authored.
  • We already have Active as a submission category. Active as the tab name also is confusing.

--Beghelli (talk) 05:05, 25 June 2014 (PDT)