Beta 2 Open Requirement Discussion - Alan/Neil

[nrshapiro]

1) Refine area

• I am fine to defer or remove the requirements on maximizing and restoring the refine area (2.3.1.2.8). The scroll seems to be fine with the number of refine areas and the limitations on length as currently implemented. If it becomes an issue later, we can handle as an enhancement. So I marked:
  • [deferred] maximize height (discuss. needed due to accessibility/screen space/too many scrollbars/etc concerns, and alternate UX patterns available)
  • [deferred] restore height (discuss needed. same as above ^)

2) General App Requirements 2.1.2

The following requirements were not yet met, they require discussion today or tomorrow:

• [ ] 17. [Core] ​The APP shall provide a means for users to copy and share the URL in two different ways: a. Share a URL pointing to current document (without the search) b. Share URL pointing to the search results and the current document (if one is selected).

• [ ] 19. [Rel.1] ​Decorations, such as the PEP Logo and other branding elements, shall be implemented in a way where PEP can replace them when new graphics are provided. Specifications for sizing of such elements and naming in the graphics inclusion folder shall be provided by the CDEV.

This latter item is marked release 1, but obviously, it concerns how things are done in development...not an admin side of things, so likely it could have been already handled, so we should discuss.

nrs/acd: Defer 17 till later, likely put it on download button/menu

nrs/acd: For now, decision to keep them in the codebase (where they are now)

3) 2.3.2.2 Middle Pane Results and Preview

• [ ] 3. Options for Export
  • [x] a. Clipboard
  • [x] b. CSV File
  • [ ] c. RTF File
  • [ ] d. RIS File
  • [ ] e. MARC 21 File

nrs: We had previously agreed that you could defer this till later. Even now, I don't see it as a problem to wait, and we can plan it out for later. (I also note it says Rel 1. in the spec, so wasn't yet due.) One issue with this though is that RIS is listed in the pulldown, but actually downloads CSV.

acd: RIS has been fixed. It wasn't implemented so it was removed from the dropdown.

4) 2.4.2.

• [bug?] 5. [Core]​ Clicking on a figure shall show the figure full resolution in a popup window which allows zoom in to 1:1 (with scroll) and zoom out.

  nrs: oddly, it didn't look like I get 100% on all images (e.g., PSYCHE.019F.0339A.FIG001), but on this one, PSYCHE.004D.0173A.FIG002 it did come up full size, and I could use the browser at least to zoom in and out. We can discuss though why this can't be done (or wasn't) in a more typical fashion.

  acd: we fit all images into a modal. Some images are super massive so they don't appear "full size" as that would take to much of the screen.

• [ ] 7. [Core]​ Clicking on a table header or non-textual element shall show the table full resolution in a popup window which allows zoom in to 1:1 (with scroll) and zoom out.

  nrs: I can see this as unnecessary for text-based tables, and graphic based tables should follow 2.4.2.5

• [ ] 8. [Core] ​The APP shall style different types of links in the text differently, per the user selected theme. Link colors shall be individually configurable in ​[​AdminMode​] ​as part of the Color Theme​.​ Link types that will be found in the XML and HTML include: a) glossary term links b) Bibliography links c) page reference links d) DOI links e) Figure Links

nrs: I think these are all "separate"...confirm, and color theme edit/install requirements?

acd: they are separate, we don't let admins edit them as a design choice.

• [ ] 11. [Core] ​A text link or icon in the reference hoverbox shall be provided to take the user to the bibliography, at the location of that reference.

  nrs: if you need an idea for this I would just put an icon at the start of the reference, perhaps a down arrow, which takes you to the point of the reference section with the reference. It could also work at the end of the reference as long as it isn't confusing with the right arrow for the reference link, or the link to the "probable reference".

• [x] 14. The APP shall provide a Translation Concordance feature between SE and GW, which when not turned off, shall operate as follows. nrs: this one is done. I've marked it as such.

5) 2.1.2 Color Themes

• [x] 11. [Core] ​The APP shall allow the user to select a theme, which minimally includes the color schema and fonts.
  • [x] a. [Core] ​Two modern color schemes shall be predefined by CDEV.
  • [x] b. [Core]​ One dark theme shall be predefined by CDEV.
  • [x] c. [Rel.1]​ One low-vision theme shall be predefined by CDEV.
  • [ ] d. [Core]​ Each theme shall include a description which can be displayed to the user explaining the style design.
• [ ] 12. [Core] ​The APP shall provide a means for PEP to associate new themes, e.g., via CSS, other standard styling mechanisms, or an interactive mode in ​[​AdminMode​]​.
• [x] 13. [Core] ​The APP shall provide a means for the user to select a default "base" font size (can be settings of small, med, large, for example) independent of browser zoom, and a quickly accessible means to enlarge and reduce to the next text size during use without side effects to other apps.

I think these should have all been pretty readily doable. We should discuss why they weren't.

acd - We can do d pretty quickly but I think the names of the themes are pretty descriptive. 12 was intentionally left out as it's more complicated and there's a lot to consider when doing a new theme.

6) 2.6.3 Preferences

• [ ] 1. [Rel.1] ​Any required settings to set features to meet the standard for disabilities and compliance should be included

nrs: I presume this is just not done because it's Rel.1

acd: basic wcag is covered

• [x] 4. [Core] ​The user shall be able to select the default base font size independent from Theme; all other font sizes shall be relative to this choice.

nrs: Isn't this already implemented as described?

acd: this is done

• [ ] 6. [Rel.1] ​The user shall be able to select which ​Info Cards​ to show. PEP may designate some though that will always be included.

nrs: The first part of this is done. It's the ability to mark some that will always be included is not done. But it's for Rel.1

• [ ] 17. [Rel.1]​ The user shall be able to configure a small avatar for the user menu.

I presume this is just not done because it's Rel.1 (Not a very important one. It was put in because it seemed easy and many systems allow for a profile based icon. We could probably just drop this.

7) 2.2.1 Feedback and Error

• [x] 6. Link and error reporting form for data errors
• [x] 7. App feedback form

nrs: Both are done. Marked.

8) 2.1.2 Accessibility/WCAG

• [ ] 7. The APP shall meet ​WCAG 2.1 Accessibility guidelines Level A​ or better. As part of this standard, it's important that the keyboard shall be an alternative to mouse selection in all cases. Some important core shortcuts that should be included:
  • [] a. Hide side panels (and individual shortcuts for left and right panel)
  • [x] b. Search (takes you right to the main search entry box)
  • [x] c. Next/Prev (usually arrows), context sensitive, e.g., to next entry in results, next page in a paged document, ...
  • [ ] d. Maximize, minimize, restore current pane
  • [x] e. Tab b etween fields
  • [ ] f. Enter f​ rom search field to initiate search
  • [ ] g. Open (usually enter or spacebar) to open the currently selected item

nrs: some are clearly done. Confirm and discuss acd: we only implemented keyboard shortcuts from https://github.com/Psychoanalytic-Electronic-Publishing/PEP-Web-User-Interface/issues/277 We can add more if you'd like

• [ ] 8. [Core] ​Keyboard shortcuts shall be configurable by PEP via ​[​AdminMode​]​.

nrs: not really sure this is key to do.

acd: agreed, i don't see the value and so we should hold off

• [ ] 20. [Core][Admin Mode] The APP shall allow easy and extensive configuration by PEP of defaults, default appearance, default data.

nrs: partially done at least. Confirm and discuss

acd: this is done. If there are other items we want configurable we should discuss

9) 2.7 Admin

• [x] 2. [Core]​ AdminMode shall provide configuration as it affects various APP features tagged throughout this document.
• [ ] 3. [Core]​ There shall be two levels of admin ID...Moderator and Admin.
• [ ] 4. [Core]​ Admin control privileges shall include all items referenced throughout doc a. [ ] Theme mapping b. [ ] Center pane home page top text nrs: more or less done...not clear if we want that to include the main byline ("A psychoan...fingertips)? c. [ x ] publisher info for each source nrs: done, marking here d. [ ] info card order in the stack nrs: done, marking here e. [ ] info card positioning (left or right) nrs: done, marking here f. [ ] hide or show the refine pane nrs: not done...not sure we need this anymore g. [ ] any other settings in appsettings.ini
  h. [ ] all moderator privileges

nrs: added the detail here, missing on plan.
acd: the concept of a moderator doesn't exist in PADS. If that gets added we can grant admin access but that's postponed for now.

• [ ] 5. [Core]​ Moderator configuration privileges shall include a. News and Info Area
  b. Expert Pick of the day c. Curated info cards d. Announcements (for message area) at the bottom of the window.

nrs: No separation yet, but we don't have (a) or (d), do we? To discuss. acd: see above

10) 3.1.1 General Rules of the responsive interface (for Mobile) [Missing from Plan, all core]

1. [x] Side panels shall hide when the screen gets too narrow
2. [x] A representative icon or hamburger menu shall give the users control over the visibility of the side panels
3. [ ] The info pane shall hide first
4. [ ] The left pane (search, browse, or reading list pane) shall hide next
5. [x] Opening the left pane shall slide the middle pane to the right so it's partly visible
6. [x] Choosing an operation on the left pane, i.e., invoking a search, or choosing a document to read, should hide the left pane
7. [x] Choosing an operation on the left pane, i.e., choosing a document to read, should hide the right pane

Done: #1, #2, #5,

Trying to use the site on my Google Pixel 4a (though I'm not a regular phone user), I'd have to say the site is unusable.

1) In landscape mode, it was difficult at best to see anything once I got to the article, because of the headers.
2) In portrait mode, the home page left box was so large, it took over the screen. I could however, pull out the left panel and search, but the document text, which was "default" since I was not logged in, was so large, I couldn't read it.

Perhaps the default text size for a phone needs to be smaller. But I think we'll need to rethink quite a bit on this.

I'm sure it works better on a tablet.

acd: we've done testing on mobile and it's worked well. Landscape is tricky with such low amount of vertical space. I can have qa look at a pixel 4a

[nrshapiro]

FYI

[nrshapiro]

@ocappello @davidtuckett @jordanallen-dev @SophieMBennett

As I look into the missing translations feature as I mentioned in the Monday's meeting (e.g., ANIJP-TR, ANIJP-IT, etc.) I'm realizing that while I implemented it in the server, I think I left it out of the client design spec (at least I can't find it in there browsing it quickly). The related documents infocard is used for artqual links, not origrx based links (per the DTD). However, the server returns matching origrx document data for any document in the translationset field of the documentlist item returned.

I will open a new issue to have that functionality added to the client with some thoughts on that.

(And having to go find that spec in my system was an issue too...but it's here, in my Google drive. I will find somewhere to archive it for PEP since many of the features in there were never implemented in the client due to the project overruns.

Link: https://docs.google.com/document/d/1yCs7VB57TSTMKynxqS-Qo2kPivEuk3D_4a0Z2NSBLNs/edit?usp=sharing