Mobile UI Development Best Practices for 2018

[HankG]

I decided to make the next issue I pulled to be 7840 since it is I feature I was interested in seeing and it would give me a chance to dive into front end code rather than back end code. I’ve been spending several hours acquainting myself with the dichotomy between the mobile and desktop UI. Before I start on even dabbling with any changes, much less the making real ones, I had some questions on the Mobile UI best practices which I can’t definitively divine from the present documentation. I’ve searched here to see if there were some topics but there aren’t really except for discussions about a heavy refactoring of the whole UI/frontend part of the stack back in 2014 (IIRC) and earlier this year. There are some dribs and drabs about moving shared JavaScript around and eliminated custom libraries etc., which only partially relates to my questions.

When I look at the code base I’m seeing that much of the HAML code is not shared between them but instead there are parallel pieces that do the same thing. This is probably exacerbated by the fact that in some cases, this one in particular, a lot of the logic in the UI is actually in Handlebar and Backbone JavaScript code. As far as I can tell neither Backbone nor Handlebar is loaded in the mobile version of the site (I’m looking at the browser-side list of loaded source files to confirm this). So first question is: is this an artifact of the design evolution of the mobile site or are these libraries explicitly being excluded from mobile browsing for performance reasons or something along those lines?

Assuming I am correct about not having the handlebar/backbone code base available for mobile use then code reuse between the two will be limited outside of the controllers I imagine. I believe this is considered okay since there isn’t really a place for shared JavaScript code and the HAML files for the two are mostly separated (there is some partial loading shared between the two in a few places). My second question is therefore: Is the mobile developer supposed to lean more towards code isolation between the two platforms rather than code reuse? For example, if in doing a feature I see that I could refactor something to have shared HAML files between the two would that be considered a negative thing and therefore should be avoided?

Lastly, assuming (I’m two assumptions deep now, which is probably a bad idea but…) that we are leaving the code isolation and not bringing in handlebars/backbone into the mobile version of the site, my third question would be: should a mobile UI developer be approaching that application more like a traditional Rails app but with HAML instead of ERBs, using existing UIs for some guidance on where to bring in JavaScript “accents” (for lack of a better word)?

I’m looking forward to working on this feature, but I figured it’d be good to check in on this after having collected my thought son it.

[goob]

Pinging @flaburgan, who was very much involved in the mobile development. He should be able to give advice on this.

[supertux88 (Benjamin Neff)]

@HankG

are these libraries explicitly being excluded from mobile browsing for performance reasons or something along those lines?

Yes, that’s one reason of the mobile interface. If we have good working responsive desktop UI and the phones are getting fast enough, we can just drop the mobile interface. And if there is an API, apps could be created for phones. So the long term plan is probably to replace the mobile UI with a new/refactored responsive desktop UI and apps, but who knows how far away this future is.

@HankG

For example, if in doing a feature I see that I could refactor something to have shared HAML files between the two would that be considered a negative thing and therefore should be avoided?

I would say it isn’t worth it to do big refactorings in the mobile UI, because it probably will be replaced/removed in the future. However, I personally like to do refactorings and cleanups, so I can’t stop you from doing so But when you do, please do the refactorings in their own commits.

If you can prevent duplication with reasonable effort, I think that’s a good thing

@HankG

should a mobile UI developer be approaching that application more like a traditional Rails app but with HAML instead of ERBs, using existing UIs for some guidance on where to bring in JavaScript “accents” (for lack of a better word)?

I think so? I don’t really know how a traditional rails app works, because diaspora is pretty much the only rails app I ever worked with But assuming you were right with the previous two assumptions, you’re probably right here too (am I now 4 levels deep? ).

[flaburgan]

Hi! Thank you for wanting to help improve diaspora. As Benjamin said the long term goal is to get ride of the mobile version. Unfortunately it looks like this will not happen in the coming months. So waiting for it, improvements to the current mobile version are welcome. On that point I would say that the ability to mention users by taping @ and have an autocompletion available is the most important missing feature.
If you find duplicate code between mobile and desktop and you want to share it in a partial please do! The less we have duplicate code the better.
Please ask if you have other questions and thanks again.

[HankG]

Thanks for the feedback @supertux88 and @flaburgan. I have a path forward now. I will look into the autocomplete on users thing as a potential follow-on to the ignoring/blocking feature. I agree that that too is a feature I find sorely missing when I use the mobile version.