Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Considerations for annotation & comments #1017

Closed
krusynth opened this issue Jun 24, 2016 · 5 comments
Closed

Considerations for annotation & comments #1017

krusynth opened this issue Jun 24, 2016 · 5 comments

Comments

@krusynth
Copy link
Contributor

There are several weaknesses with the current annotation & commenting design:

  • Discussion tab isn't found by most users.
  • Users do not have an easy way to ask questions directly (probably due to the above item).
  • Annotation is a confusing word.
  • The current annotation process is not intuitive or expected.
  • Annotations are hidden by default, so it's impossible to see the actual discussion.

We should use this thread to discuss potential solutions, but we need a total UX overhaul here.

Here are a few ideas I've thought of:

  • Always show the annotations, perhaps collapse some of the content. (How does this work on mobile?)
  • Don't require users to select-to-annotate - use some sort of annotation link/icon instead. Maybe this is per-paragraph, off to the side where the current annotation icon is. (We could eliminate Annotator altogether this way.)
  • Change the annotation process to make the suggesting vs commenting process more clear.
  • Move or eliminate the discussion tab.
  • Allow some sort of prominent FAQ area, or perhaps allow admins to flag comments/annotations to include in this?
  • Allow some sort of summary/alternative content. Many of our documents are in legalese, and many of our users are unable to understand them well.
@sethetter
Copy link
Collaborator

Per a discussion earlier about implementation considerations on the client side going forward -- if we are going to be rethinking the UX on the document page quite a bit, it would be a good time to consider technology choices there.

There's been talk about moving to server side rendering, which I think is completely logical for the majority of our application. The one place that still needs high level of JavaScript help to really get the UX right is the document engagement page.

For just a single page, we wouldn't need to use a full-featured framework such as Angular 1 or 2, or Ember either for that matter. I'm thinking it would be best to consider something more minimal such as React or Vue.js. I'm going to dig in on these and see which one appears that it will best fit our needs.

Regardless of which choice we make, I would strongly urge us to use this opportunity to move away from Angular1. If a large amount of the code for the most interactive piece of our application is about to change, now would be the time to do it.

@krusynth
Copy link
Contributor Author

Personally, I would like to avoid many of the current hoops we have to jump through as a result of the Javascript-only frontend. (Notably social links, among many, many others.)

In my ideal world, the entire page would be compiled and delivered by the server - it's not that much content - and dynamic elements only swapped when the state is changed. We don't need two-way binding or persistent polling of any of the data on this page - only to update when the user does one of the three (or so) actions available here. This also allows us to cache the entire page at the server level (via Varnish/Nginx/etc) which would be much better for performance too. Anything heavier than a simple Ajax request on this page seems like massive overkill and resource-hogging to me. (We will, however, eventually need polling for #1010 - but not two-way binding still.)

But that's just, like, my opinion, man.

@sethetter
Copy link
Collaborator

sethetter commented Jul 11, 2016

Went through all the issues today to try and find anything related to document page UX, here's a rough list:

Also, regarding the possibility of switching front end technology choices, these issues could/would be addressed:

There could very well be more, feel free to add!

@krusynth
Copy link
Contributor Author

The good news is, that's almost 10% of our open issues! So if we do this right we can put a big dent in things.

@sethetter
Copy link
Collaborator

Closing this due to UX overhaul in v4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants