Loomio
Wed 16 May 2018 6:59AM

UX Feedback: Load Times, Navigation, and Editing Comments

DS Danyl Strype Public Seen by 101

I'm back to using Loomio more regularly after being mostly offline for about 6 months, and mostly inactive on the site for more than a year. It's great to see all the new features that have been rolled out; the new poll types, the instant preview option, the toggle between chronological and nested comments, and so on. As always, it's clear that a lot of thought is going into what features to add, based on regular user feedback here, which is awesome. Go team! That said, there are a few things that could use some work.

Site performance

I use the web on an older computer (details here: https://www.coactivate.org/projects/disintermedia/bishop), on a pre-fibre broadband connection, and Loomio.org is very slow for me. It's the only site that regularly results in my browsing popping down a warning saying "a web page is slowing down your browser", and asking if I want to stop it or wait.

On a couple of long threads I was catching up on, I actually found myself copying the whole page and pasting it into a text browser to make it easier to read. What I'll do in the short term is just start to interact with my Loomio groups as email lists, and it's great to see how mature the email integration is now. But here's a few things that might help.

Firstly, there seem to be lots of unnecessary page loads happening. For example, if I click on a notification that refers to a comment in the thread I'm already reading, the entire page reloads, instead of detecting that the correct page is already loaded, and just moving to the part the notification refers to (with anchor links or something).

Changing the comment order from chronological to nested and back, or from old to recent and vice-versa reloads the whole page, instead of just the bits that actually need to change (is there a way to expand all comments instead of having to click 'show more' on each one?). I also notice that when I go from a group page to a thread, then back to the group page (by clicking in-page links), the thread list reloads instead of pulling a copy from a cache, as does the list of group members. Are processes like these hitting your database every time? :(

This was one of the main things that caused scaling problems for the early Indymedia sites; Apache could serve HTML pages much faster than the PHP scripts hitting MySQL could generate them in realtime. This problem was solved by using a Squid proxy that held a copy of every static HTML page that would ever be produced by every script on the site, and having the scripts push updates to every relevant page in the proxy whenever the database was changed (by an article or comment being published etc).

I get that a system like this is much more complicated to design once you add user accounts, your permissions scheme, and so on. But the performance improvements for users, and the burden lifted from the database, might make it worth the effort. It might also allow people to read the site without JS turned off; at the moment, without JS, the site is blank. It ought to be possible to read text and look at graphs without JS, although obviously scripts are needed for any interaction with the page.

Editing comments

Does it need to be a non-movable pop-up modal? Could it not just be a little box nested in the page, like when writing them in the first place?

The way the line I'm typing in moves to the bottom of the page every time I type makes it really hard to edit comments for sense. If it's going to jump around, it would be better to make it the middle of the page, but jumping around is annoying behaviour in general, and best avoided. It
creates a mini-context switch every time it happens, which really blows my train of thought.

Loomio and Enspiral continue to give me hope for the future of ethical tech, deep democracy, and the world in general. Keep up the great work!

RG

Robert Guthrie Wed 16 May 2018 7:33AM

There are a few places in the app where we could be showing records but we wait until loading is finished. I think we've agreed we will show records and show a loading spinner at the same time (probably at top of the list). So.. some of this can be improved.

However, often It turns out that loading full record sets again rather than just what is missing is way less buggy when it gets to complicated things like nested records.

You know the drill, we're a tiny team and this stuff costs. We have to choose to serve the most people we can, the most feature rich experience we can, and you seem to be on the fringes of most with your setup.

That said, we're aware the app is quite CPU heavy, the change required is significant. The waiting warnings you experience are probably due to the Angular 1 digest loop. Our long term goal is to create native apps as well as gradually rewrite the web app in something fast. Significant steps towards this have been made. In the meantime a faster computer will cost a lot less that our time to optimise and fix it.

I agree that the input widget is really annoying, both on desktop and mobile, and I think we need to consider dropping the angular-material textarea for a normal one with some css added, because it's jumping drives everyone insane. Both on mobile and on desktop. I expect it's not too hard to recreate a material looking textarea without the angular-material issues.

DS

Danyl Strype Wed 16 May 2018 9:15AM

@robertguthrie

you seem to be on the fringes of most with your setup

Granted :) But you could look at me as a coalmine canary; the performance issues I describe affect all users (esp. mobile users on metered internet), they're just more noticeable on my setup.

Our long term goal is to create native apps

That's great. The age of the web app ("port 80 pollution") was forced on us by users behind corporate firewalls with only port 80 open, and no admin rights to install client software on the device they used online. The move to mobile devices with app stores, and work laptops administrated more by their users, is allowing us to re-normalize using apps outside the browser. Despite the dev costs of supporting multiple patforms, there are significant performance and security advantage to native apps.

You could even consider charging users a modest fee to download clients from app stores. Keeping the code under free license, as well as being essential to respecting users' software freedom, would allow those who are broke enough for compiling from source to be worth the trouble to still use them.

as well as gradually rewrite the web app in something fast.

What about using some kind of static website generator, using JS only when the use pushes changes to the database (eg new thread, new comment)?
https://www.smashingmagazine.com/2015/11/modern-static-website-generators-next-big-thing/

At the risk of labouring the point (I'm guilty of this a lot I know, sorry), if Loomio has to generate a new HTML/CSS page on-the-fly each time a user loads a page, that's lot of computing work. If each page generation action has to query the database, there's only so much of that you can outsource to the user's browser via JS. If clicking a Loomio link to read something (as oppose to change something) just hands the user's browser a pre-cooked .HTML file, that's a whole lot less database queries, and a whole lot less processing for both the browser and the server.

I notice that all the sites that give this laptop trouble (Loomio, Diaspra, MetaMaps) are RubyonRails apps. The most experienced programmers I know tell me RoR (like PHP) is great for rapid prototyping, but there are hard limits to its ability to scale and remain maintainable and extensible. Maybe it's time to think about refactoring in a different language/ framework?
https://thenextweb.com/dd/2017/07/26/ruby-rails-major-coding-bootcamp-ditches-due-waning-interest/

EDIT: see also the HN thread discussing that story:
https://news.ycombinator.com/item?id=14863272

In the meantime a faster computer will cost a lot less that our time to optimise and fix it.

I'm realise that you're not actually suggesting I do this, just making a point about the political economy of the situation. But "replace your working PC with a newer" one is not ecologically responsible advice ;-P I see it as an ecological advantage of free code software that many eyeballs can be harnessed to find ways of tweaking the code to do more with less computing resources. A radical strike against the traditional 'planned obsolescence' of hardware industries.

RG

Robert Guthrie Wed 16 May 2018 9:33AM

Sorry, but you're too far out of context for suggestions at this level to be of help.

DS

Danyl Strype Wed 16 May 2018 9:49AM

Fair enough, feel free to ignore them. When you're up to your arse in alligators, it's not always helpful to be reminded that your big picture objective was to drain the swam. But maybe there might be others in the Loomio team (or the community in general) who are more interested in longer term architectural brainstorming?