Define the new DBlog UI

What is the use case for removing individual log entries?

One of the most important parts is to demonstrate "UI overriding/extending" (the Drupal Core way, don't kill a kitten. and no NODEJS on server side). It demonstrated how to avoid overhead (on the resources loading).

Other parts, we can checkout TodoMVC & HackerNewsClones to do a comparison.

my list
- demonstrate Theme part
- demonstrate Routing
- demonstrate overriding/extending

Not in my list:
- (CRUD really not a must IMO, checkout TodoMVC)

1 demo for normal module UI
1 demo for overriding/extending the UI above

How about an enhancement that lets you select 1 log item, and add a 'solution' to it (be it an admin note + link to d.o or StackExchange), permanently store that log item and in the future, flag matching error messages in the UI as having a potential previous fix. This would add some interactivity beyond the basic filters we already know, add a useful feature, and per Chi's comment - store a log item for reference as an action.

Awesome. Very exciting.

The cooler side of my brain is reminding me that the React issue is allowing comments till the 23rd and we should be mindful of that and the process the core team set forward before rushing too far though.

Discussed this issue on today's UX meeting. Recommendations were:

• A "stage 1" version that just recreates admin/reports/dblog seems like a good place to start. Key things to look for: what does it mean to override core's output? what it means to provide themeable output from a JS framework? (Basically, what @droplet said.)
• The "stage 2" having improvements over the existing UI:
  • Show off what these libraries supply out of the box (or with a popular add-on) for the multiselect pattern? (e.g. pills/buttons?) Core uses the HTML version which is pretty awful UX.
  • Also explore alternatives for "expand-in-place" functionality for longer entries that get cut off with "..." (currently just uses the 'title' attribute on the link)
  • Search box: Filtering the results by keyword without a server refresh.
  • Auto-update as new logs are created as you're looking at the page (suggestion was to use Twitter's "X new log messages" pattern that can be expanded to include them)

Also, from our understanding, the Form API parts are a whole rats' nest, which is why this screen was chosen vs. something like admin/content. So would recommend descoping the bulk select + delete items from the prototype.

Adding @yoroy and @benjy to the credit list for this issue, since they were part of the above discussion.

Also,

A fair comparison should use SAME THEME MARKUP as the current DBlog without Views classes. Or the same markup structure. For example, web components may use CUSTOM-TR represents tr tag is acceptable. (But try to avoid it IMO)

Less or More markups, we should count that as framework limitations. (e.g. what @effulgentsia cares #2909481: JavaScript VDOM library evaluation: components returning multiple root nodes.)

Seems like we have to close this first, haha: #2915314: No spaces on icons' classes

Discussed this issue on today's UX meeting.

I wasn't part of that discussion :) - maybe you confused me with someone else?

As part of playing around with my solution in elm I realized the following bits:

• Search box: Filtering the results by keyword without a server refresh.

  This has an issue to be actually practically useful. You want to filter quickly the entries you currently see, but then have also an HTTP request running in the background fetching additional entries which are valid for your current filter criterias.

• Auto-update as new logs are created as you're looking at the page (suggestion was to use Twitter's "X new log messages" pattern that can be expanded to include them)

  I think its really nice to provide something like acquia's hosting interface, aka. new messages are streamed in, so you can see them directly,
  especially helpful if you filter by severity. This is totally possible, but it requires work on the server side though.

At least for me I have no doubt that any framework/approach can filter/sort nice, can apply things in real time and what not, but I think the actual problems are:

• Themeablity
• How do multiple apps pages work together (do they have to?)
• Is something like a form alter still needed?
• How do modules hook into the process and provide additional functionality?
• How maintainable do these approaches end up with? Something which looks maybe verbose now, might provide long term benefits

Oops, my bad. :D Sorry, @benjy!

@Attiks I think we want to exclude the "Clear all logs" button from the design you posted.

The show all logs button seems also quite, well let's say, not really working in reality :)

Something I did not seem mentioned is the fact that this UI should both /also/ work with JS disabled and remain accessible, should it not ? Not sure whether this goes on this issue or on the respective React/Vue/WC issues.

At least for me the approach to do that would be to have a frontend router taking over the page completely, so the backend doesn't have to worry about that.

#26 that's what I think too, and it means we do need to add a noscript behavior, which may impact what we put in the server-side markup, to enable these reactive behaviors as a progressive enhancement.

Make them use Views on server side for filtering and getting results (REST export).
/ducks ;)

re #24 - #27: We had a blind person in our office recently, demoing his screen reader. We didn't get into much detail on the topic of JS, but the takeaway was that screen readers do support JS (http://a11yproject.com/posts/myth-screen-readers-dont-use-javascript/). You do have to take care of accessibility when building your application though; here's a good article on client-rendered accessibility.

I'm not sure if the choice for a JS framework (React, Vue, whatever) makes much difference when it comes to accessibility. It's mainly a matter of generating semantic, accessible HTML, placing ARIA attributes where needed, and JS for managing focus and notifying the user when content is dynamically updated. Every framework should be able to do that, I suppose... But I might be wrong.

Re: #29 - thanks @marcvangend, that's pretty much correct.

Tagging this for review later on, but I think much of the accessibility review will be done as part of an implementation issue. So far, I haven't seen anything in this design that we can't convey in an accessible way. The exact approach can wait until we have a working code prototype.

For example, we'll need to convey something like "Now showing 8 results for type: PHP severity:warning", but whether to use Drupal.announce() or a dedicated ARIA live region is something we can decide later. A visible now-showing summary message might be useful too.

Similarly, we'll want to convey whether a particular filter is active while a user is focused on a button. Matching the visual style with aria-pressed is the typical way to achieve this. The new role="switch" from ARIA 1.1 may be appropriate too.

The designs don't show a waiting/thobber widget yet. Depending how that looks visually, we could:

• Mark the table container as aria-busy, or
• Treat a thobber icon as a dedicated aria-live region which announces "fetching.... done" messages, or
• a combination of the above, or
• something else.

WAI-ARIA 1.1 introduces an aria-current property, which can make the pagination links more robust. In fact, we could use that on pagers everywhere - see #2893640: Modernize ARIA usage, in line with ARIA 1.1 and the ARIA Authoring Practices guide..

screen readers do support JS

It's more accurate to say that web browsers support JS, and communicate changes in the DOM to screen readers. The screen reader isn't handling JS itself, just reporting what it gleans from the browser. There's a good overview of how screen readers work in Accessibility APIs: A Key To Web Accessibility from Smashing Magazine. In the modern way of doing things, the browser and assistive technology communicate with each other via an accessibility API provided by the OS. Some screen readers (e.g. JAWS) also still employ a historical approach to access the browser DOM directly, but modern browsers' security/sandboxing are moving to prevent this.