Archives pour la catégorie Design

uTranslate : first design recap

Now that the contest is finished and while waiting for results, I can take some time to explain the design of uTranslate.

First, I had big constraints : only 3 weeks available, no knowledge of QML. So I had to choose a simple subject. A subject that needs as few as possible work for the engine and that allows me to work on the UI.

For my own needs, I thought about a traffic app (a port of an android GPL app). But after digging into the code, it was not so simple : gathering datas was an ajax request, but rendering them involved a lot of work. My next need was a translation app. After few searches, I found the glosbe website, with their open API (an ajax request) and their call for opensource. Bingo ! it’ll be a translation app.

A friend of mine is german and I looked at her using her iPhone to translate some words while we were talking. So use cases were defined « live » !

  • she starts app, type first letters of a german word, app suggest a list of words, select one suggestion and she sees the french translation ( the lang german/french were predefined)
  • I take her phone, switch language, and perform another similar translation

The main idea is « efficient » : every saved click/tap is very important :

  • when the app is started, it must be able to receive immediately an input form user :
    • the lang must be what the user has already defined
    • the focus is on the search text
  • list of suggestions is very important : it allow the user to NOT type other characters
  • given the small screen size on phones, the list of suggestions should appear above other elements.

The Glosbe API bring some changes : it allows 2 calls : one for translation, another for definition. How can I integrate that ? A first idea is tab under the search text.

design1

But in the Ubuntu Touch UI, tabs are always at the top of the screen. And each tab has his own content. So I thought that it would be interesting that both tabs share the same context : the languages and the search text should be identical in both tabs.

I made a very first prototype to discover QML and test this idea. Thanks to QtCreator autocomplete feature, I quickly found the ‘onSelectedTabChanged’ and ‘onSelectedTabIndexChanged’ : my idea was working well ! The core of uTranslate was ok.

Then, the « popopver » effect of suggestion list was made with the « z » property. Plus 2 animation for expand/reduce. Cool.

Initially, there was more buttons beside the search text : a « search » button and a « switch » button for the « translation » tab. But after some testing, it appeared that :

  • « search » button is useless : we always use the suggestion list or the « enter » key on keyboard,
  • the « switch » button is not so important, so I moved it in the toolbar,
  • the look of flags buttons is not very good : I replaced the standard buttons by pure Image with a MouseArea

The result is a very clean search UI, with much bigger flags, without visual annoyance.

Then the « settings » and « about » pages were added in a general PageStack object. When user comes back in translation/definition tab from one those pages, the focus is on the search text and suggestion list appears : the app must always help user find a word. If it doesn’t behaves like that, it’s not a feature, it’s a bug ! ;-)

As I’m not a graphics designer/artist, I didn’t try to define new colors. I know this is a strong effect that help users say an app is beautiful. But it’s better I ask someone to do it. I just made a simple icon for the contest.

This is the current version 0.2.1. I think that it fully respect the initial idea : no whizzbang features, just efficient, efficient…

Obviously, I think about some new features, but I’ll try to always keep that initial idea of efficiency.

PS : Oh, I forgot to tell that the « .1″ in « 0.2.1″ is because I found the U1db bug ! it was the filename in the definition of the database. Weird…

uTranslate : version 0.2 submitted to AppStore !

Yesterday, I could create version 0.1 and upload it on AppStore !

And today, I finally created version 0.2 of uTranslate :

  • list of suggestions has correct text size, correct clip
  • list of suggestions has a visual effect when selecting an element
  • lang selector has flags without visual artefact (it was related to the fact that icons have to be square images)
  • added an information for user if network error

Unfortunately, it seems the U1db storage works only on the desktop.
After tests, some problems appear with OSK  in landscape mode : it seems that the ‘tap/click’ event is propagated to other widgets.

Here are some screenshots taken from my Nexus 7 :

uTranslate5-1     uTranslate5-2

In landscape mode :

uTranslate5-3

A new visual effect when selecting a suggestion :

uTranslate5-4

 

uTranslate : Convergence & storage !

Full steam ahead !!

uTranslate now stores the languages chosen by user : when you close and restart uTranslate, you find your last settings. And it handles convergence : the layout is modified to handle big screens.

Here is the standard (phone) layout :

uTranslate3-1

And here is the layout for tablet/desktop : the suggestion list is always visible :

uTranslate3-2

uTranslate3-3

uTranslate3-4

uTranslate : week 2

I worked on improving layout and UI for ‘phone’ layout :

uTranslate2-1

When you start typing, the suggestion list appears, like a popup under the text field :

uTranslate2-2

And the suggestion list disappears when you click on ‘search’ or a suggestion :

uTranslate2-3

It’s the same state when you switch to other tab :

uTranslate2-4

And the suggestion list appears as soon as you tap on the search field :

uTranslate2-5

The ‘settings’ button moved in the toolbar :

uTranslate2-6

And it is a simple Sheet :

uTranslate2-7

But this will be changed in the future, as Canonical designers said the official place for settings should be in the HUD.

Of course, the layout handes other screen sizes (but it’s not ‘Convergence’) :

uTranslate2-8

uTranslate : first week, screenshots !

Here are the results of one week of work on uTranslate !

QML is really a fantastic technology ! It’s the first time that I use a tool that seems to be perfect for GUI coding. It’s light years better than other I used : MacApp, HTML+CSS+JS, XUL. In my opinion, it’s on par with Apple’s tools (InterfaceBuilder) while being different : QML allows to write controller’s code beside or even inside the UI declaration ; while InterfaceBuilder clearly separates UI and code (well, last time I used IB was few years ago).

So I created foundations : basic UI (2 tabs + a shared context), handling of ajax request to glosbe server, language selection, basic user interaction.

And you’ll see that everything remains to be done about layout&convergence : that’s the subject for next week ;-)

Here is the default screen :

uTranslate-1

As soon as you type, you see suggestions :

uTranslate-2

If you tap on a suggestion, it chooses the suggestion and perform search :

uTranslate-3

Whenever you switch to tab « Definition », you keep your search and suggestions :

uTranslate-4

 

If you change the destination language,  the translation is performed :

uTranslate-5

uTranslate-6

Here is the screenshot after « Italian » selection :

uTranslate-7

uTranslate for UbuntuTouch !

I decided to enter the Ubuntu App Showdown ! (http://developer.ubuntu.com/showdown/ and  https://wiki.ubuntu.com/Touch/AppShowdownList)

I plan to write a dictionary/translation app : « uTranslate ». The online engine will be provided by Glosbe.com, thanks to their simple API (http://glosbe.com/a-api) and their support of OpenSource (http://glosbe.com/a-api#H2_Share). Maybe future versions  will handle other providers.

As the deadline is September 15th, it’s already a difficult task !
And I have to learn nearly everything : QML, QtComponents, Click Packages !…

Well, the good news is that the online engine already provides the expected behavior : I can concentrate on design & coding of client app.

 

 

Ubuntu Touch : an emergency mode ?

When friends came home, I let them try UbuntuTouch on my Nexus7. First, I just said « use edges ».

They started and found easily the launcher, then launched gallery, then an image in full screen, and then… lost ! They were stuck on the image, tapping/swapping on the image as much/fast as they could.

I had to tell them « the toolbar is in the bottom edge and there is a back button ».

All this made me think : « what if… there was an emergency mode ? »

Here is a proposal ;-)

proposal_emergency_1

If you have ideas about other gestures that can be mapped to the « emergency mode », please tell me !

Ubuntu Touch : about the « Back » button

There is an interesting thread in the ubuntu-phone mailing list about the « back » button : https://lists.launchpad.net/ubuntu-phone/msg02260.html

Some early users are complaining that :

  • it’s not easy to discover (specially for new users),
  • it needs two taps

Several proposals have been made, but only described as text. I tried to make some proposals with more precise mockups :

1 – a « back » button as an overlay, with 2 variations

proposal_back_button_1

Pro : only one tap, very easy to discover
Cons : doesn’t respect the Ubuntu guideline : « no controls, just content »

2 – a back gesture

proposal_back_gesture_1

Pro : respect the Ubuntu guideline « no controls, just content », very similar to notification’s gesture
Cons : stil not very easy to discover

Finally, as each proposal is interesting while not being perfect, I think that Ubuntu touch may let the user decides which one he wants to use : it may be defined in settings :

The « back » behavior is implemented through :

  • a « back » button in the toolbar
  • a « back » button as an overlay
  • a back gesture from the bottom edge

 

Thoughts about Libre Office design process (part 9 : conclusion)

As a reminder, here is the list of all the articles :

In few words, the main ideas are :

  • the TDF should define a long-term strategy with a roadmap
  • the TDF should define rules to be sure that every part of the roadmap is executed (ie important functionalities are developed on time instead of developers working on non-important functionalities)
  • the TDF should have control over branding
  • the current design team has skills only in graphics, Visual Identity, not in User Experience
  • the current design team lacks some basic professional knowledge and behavior
  • the design process should be handled by a new team with proven skills in UX design
  • the design process should be completely enhanced to become professional, with interactions with others teams (devs, VI, QA, A11y…), use cases, guidelines, iterative process, prototyping, specifics tools and rules to use them, user feed-back and schedules

Consequently, subjects for « easyhacks » or GSoC with GUI should be designed before any work on code. Today, the implicit message is « Come in and code, we’ll check UX later« . It should be « Come in, help design/prototype and then code« .

I know that in FOSS world, there are mantras « release early, release often« , and « consider users as testers« . But, as LibreOffice  has millions of users, it’s not possible : LibreOffice must provide rock-solid and perfectly designed functionalities from scratch, from the ‘.0′ release.

Even if it is a strong criticism of the actual design process, it is also a constructive criticism, with proposals. And as I am pragmatic, I’m currently working on some ideas for Impress with these methods and tools. It started as a question on the ux-advise mailing-list (http://lists.freedesktop.org/archives/libreoffice-ux-advise/2013-March/001876.html). And I expect to have good results. Everything will be on the ux-advise mailing-list.

I hope TDF will hear my feed-back and provide an appropriate answer to that urgent problem. The future of LibreOffice depends on it.
If nothing is done about the design process, as a domino effect, all other parts of LibreOffice will have problems, and I really feel sorry for developers, translators, testers and users.

 

Addendum : As a proof of my fears, there is the last version of ColorPicker (https://wiki.documentfoundation.org/Design/Whiteboards/Color_Picker and http://ubuntuone.com/57jcpbGE2SGHXlzw1JjY2n) : while looking interesting, some parts show that nothing has been learned from the TemplateManager or previous ColorPicker :

  • what about use cases ? (the mockup is described as « explains everything » !)
  • will it be ok for all parts of LO ? Writer, Calc, Draw, Impress, Preferences…
  • they expect « themes », but is it really a planned feature ?
  • they expect to have « live preview » of colors : no one dev confirmed it is easy to implement (and it’ll be completely inconsistent with all other popups)
  • they expect to work with « mm » instead of « px », ie with resolution-independant-widgets : again, is VCL able to handle that ?
  • what about accessibility ?
  • did they prototype that proposal ? will users guess the workflow ? Will users understand the buttons ? Is it ok to have the « custom color view » in the popover ? or in a real dialog  or in a floating window ?
  • it was still designed drawn by just 3 to 6 people, without any other feed-back
  • Mirek just proposed some big changes, just 1 week before the theoretical deadline (http://listarchives.libreoffice.org/global/design/msg05729.html), a usual « best practice » of the current design team…
  • and so on…

About the template manager, there is some strong feed-back  (http://listarchives.libreoffice.org/global/design/msg05731.html) : most of those problems could have been identified with early prototypes. What a waste of time and energy…

 

Thoughts about Libre Office design process (part 8 : branding)

I also have a proposal for the branding process : branding should be done INTERNALLY : some contest may be started to receive ideas, but the processing, the creation and validation of the new branding/visual identity must be made internally and validated only by TDF members.

TDF members know what they want to obtain since they have clearly defined the objectives. As LO is used by millions of users, the visual appearance is essential and cannot be handled by non-professionals. TDF should not hesitate to pay for this specific task in order to have real professional visual branding. Thus this task will be performed efficiently in short time instead of weeks of polling.

As they answered on the mailing list, Charles & Italo should have said (instead of http://listarchives.libreoffice.org/global/design/msg05261.html and http://listarchives.libreoffice.org/global/design/msg05267.html) :

« we assume/take on our role of TDF Member and then decide :
– to stop the current poll,
– to work internally with designer & graphic artist, based on current proposals,
– to choose internally the branding for LO4 (via a poll for TDF members),

Everything will be done in few hours, and will be ok for LO 4.0.0 release. »