Responsive UI #1180
More and more users are browsing Tatoeba from a mobile device. In April 2016, the percentage of visits from mobile devices started to exceed the percentage of visits from desktops. Considering that mobile visitors are now the majority, it becomes urgent that we rework the UI to be mobile-friendly.
Below some stats from Google Analytics.
We basically have 3 solutions.
The solution we'll be trying is the 3rd one: responsive UI. We will be using Angular Material for this.
We want to make the transition as smooth as possible. There will be more or less 3 phases.
Since we'll be following the Material Design spec, we need to prepare users to get used to the new look and feel. During the first phase, we don't touch the general layout of the website. We only change small elements (buttons, icons, fonts, colors, dropdowns, etc). These changes will be introduced progressively, over the course of a month, maybe two.
This will be a good time to start a styleguide.
In this phase we start to tackle bigger elements: the menu, the search bar, the sentences, the comment, the logs... Again, we don't touch the layout of the page. We just want to redesign these elements in a way that makes them easy to migrate to a responsive UI.
In this last phase we finally start changing the layout of each page. For some time, both the old and new layouts will be coexisting, and users will have an option to activate the new layout. The new layout will be disabled by default because as long as we haven't reviewed every page, the navigation from one page to another will feel inconsistent on mobile devices.
Once we have reworked the main pages, the responsive layout will be the default one. Users will still be able to disable it from the settings. And once we're reworked every page, we will remove the option.
In order to evaluate the feasibility of this project, I've prototyped something in a separate branch: angular-material. It only serves as a technical reference. In this branch, the only page that has been reworked is the page to add new sentences (accessible from the menu: "Contribute" > "Add sentences").
It was testable on the dev website during Tatoeba day #22 and the following week.
This issue is a parent issue for all the incoming smaller issue that I'll be creating along the way to organize this UI migration. It also serves as an entry point for anyone who'd like to get involved and help out in this migration project.
The text was updated successfully, but these errors were encountered:
I just saw a couple of issues with the new interface:
…rial. Relevant to issue Tatoeba#1180
@ckjpn, maybe this wasn't clear, but we are not going to use Bootstrap or Bootstrap-looking frameworks/plugins.
We will rely primarily on the Material Design specification from Google: https://material.google.com/
Regarding the top menu, there is a section about navigation in the Material Design spec: https://material.google.com/patterns/navigation.html#navigation-patterns
Please take the time to fully explore the spec, as well as the Angular Material library. There is no need to suggest alternatives, unless you consider that the design choices that were made in Material Design do not fulfill the needs of Tatoeba users.
Ref. #269: The size of the iframe was for some reason smaller than it used to, no longer applying the defined width and height. Adding the param `data-resizable="true"` seems to fix it. Ref. #446: The params `data-initial-language` and `data-show-subtitles-default` have been added in order to have the subtitles activated by default, and displayed in the UI language if possible. Ref. #1265: A small paragraph was added explaining what is Tatoeba and where does the name come from. Ref. #1180: The container div is displayed with the `md-whiteframe-1dp` class.
So we're 3 months into the UI migration now. This is a wrap up of the work done so far, and the roadmap for the next couple of months.
From my estimations there's still at least another 6 months to go before this can be completed. But it could take one year. My initial expectation was that this migration will take around one year, under the assumption that I'll be the main person taking care of this, with maybe some help here and there.
The phase 1, mentioned in the description, is more or less over. Only buttons, checkboxes, radio buttons and loaders have been replaced. The icons, text inputs, dropdowns and tooltips were left out. They will be replaced progressively, as bigger elements are being redesigned.
We're currently in phase 2. The scope that I chose to focus on, for this phase, is to review every page a new user would have to go through (in an ideal scenario), if they wanted to contribute a new snetence. The steps are:
Addionally to these pages, there are elements that are common to all pages: flash messages (#1255), serach bar (#1294), footer (probably won't be changed), top navigation menu (to be done, probably the last task in phase 2).
Roadmap for the next few months
Currently I'm reviewing elements on the homepage.
This is a very rough planning. It is very likely that some points get delayed because some other tasks will come into the pipe.
In any case, once the top navigation menu has been reworked, phase 3 can start. Technically speaking, phase 3 is about setting the viewport on Tatoeba's pages, and re-adapt everything that needs to be re-adapted for the pages to look good and usable.
At this point of course, only the pages that were the focus during phase 2 will be affected. But this will be the first real test to see how the new design performs on mobile screens.
A few notes on UI inconsistency and slowness
I'm very aware that all these new changes with the UI are bringining inconsistencies and slowness.
Right now Tatoeba is basically under reconstruction. Until this migration project is over, the UI will look a bit odd. Some parts will look "old" while other parts will look more "modern". It's difficult to avoid this. There is of course the possibility for me to work in the dark for a whole year and release the UI changes all at once. This would avoid inconsistencies, but common experience says that this approach rarely works well.
As for slowness, it is not an easy problem to fix. It requires a lot of expertise to optimize a software. The introduction of the Angular Material framework definitely impacted the performance of the website. But this is another tradeoff. Angular Material makes the development the new UI more comfortable, less demanding in effort, but it makes the website more "greedy" of resources. Hopefully, when the whole migration is complete, and the code has been refactored accordingly, the speed will improve. In any case, there will always be efforts in trying to make the website faster.
At the moment, because most of effort is dedicated to design work, I don't have much energy left to spend on optimization. But I will eventually get there.
I still think it might be a good idea to first focus on making the website mobile-friendly (Phrase 3), and then finish converting over to Angular. I am assuming that there isn't something about the Angular code that makes this impossible to do. I also understand that you may not like this idea, so you do not need to explain your reasons if you don't want to reconsider this.
A mobile-friendly website would mean that members could more easily be translating anytime and anywhere, for example waiting in line at a supermarket, waiting in the lobby of a hospital, or sitting on a bus.
More and more people are using mobiles and tablets and these people would likely find having the site mobile-friendly soon to be more useful than having the Angular changes done first.
Here is what Google Analytics says for tatoeba.org now.
mobile = 37.91%
For comparison, after converting many of the pages over to Bootstrap on a website of mine, Google Analytics now says I get this. Before that, what I got was similar to tatoeba.org.
mobile = 60.39%
I know TRANG doesn't seem to want to use Bootstrap, but any mobile-friendly code would likely have the same immediate benefits. My assumption is that tatoeba.org could be converted over to Bootstrap in a month or two - possibly just couple of weeks with many hours of work dedicated to doing it. Perhaps it also wouldn't take too much longer using the method TRANG wants to use.