Relatório da Hackatona de Design

Durante semana, no mês de janeiro, eu estive no Brasil, no Rio de Janeiro para uma hackatona de design, com os designers de Endless e do projeto GNOME.

Que é o produto de Endless?

O maior produto de Endless é um sistema operativo para mini computadores que eles fazem, o Endless Mini e o Endless (Maxi?). O sistema operativo usa Linux e uma versão de GNOME com algumas changes (mudanças). O uso principal desses computadores é de ter muitas informações sem acesso à Internet. Por exemplo, tem muitos aplicativos sobre viagens, animais e etc que são diretamente dentro do computador, usando Wikipedia como fonte, e uma outra aplicação de receitas, com uma outra terceira fonte.

A hackatona em si

Os dois primeiros dias foram para viajar e visitar os usuários “beta” do Endless computadores, um dia na Rocinha, uma favela do Rio. E um outro dia em Magé, uma cidade rural do estado do Rio.
Os três últimos dias foram para discussões no escritório de Endless.

Observações

É uma coisa para fazer testes de usabilidade nos EUA e na Europa, e uma outra coisa de fazer isso num país sem habitude de usar “computadores pessoais” com Windows o MacOS X, mas muita mais habitude com celulares.

Por exemplo:
- Se se tem um mouse, vão dar dublo clique. Não é um problema com teclados sensíveis.
- Dividir a tela para ter um aplicativo ao lado de uma outra é difícil também.
- Se não se tem um acesso à Internet, não vão tentar instalar o acessar outros aplicativos que estão já no computador.
- Não estão acostumados a fechar aplicativos que não usam mais. Um sistema operativo de celular vai fechar os aplicativos antigos de maneira transparente.

Conclusões

Muitas coisas que o Endless ou GNOME podem mudar ou melhorar.

- GNOME tem alguns vídeos para explicar o “overview”. Um jogo ou tutorial podem ser melhor para explicar e ter certeza de que os usuários entendem.
- GNOME precisa melhorar a integração de modems celulares. ModemManager tem as funções que GNOME não usa.
- “Web” precisa de integração com detecção de malware, que ele não tem agora, mas foi uma ideia para o Summer Of Code dos anos precedentes.
- GNOME pode melhorar a primeira tela de todos os aplicativos e do sistema também, especialmente se o usuário não tem Internet para baixar conteúdo.

Muito obrigado a fundação GNOME pelas minhas passagens. Obrigado ao Endless e o Allan Day pela a organizacão. Obrigado ao meu empregador Red Hat pela oportunidade. E, enfim, obrigado à Caro pela correcção!

Videos is here!

It's been some time in the making, with the redesign work started a couple of release cycles ago, but we finally reached a state where it's usable, and leaps and bounds easier to use than the previous versions.

I should note that I use Totem and Videos interchangeably, Totem is still the name of the project, code repository, but the user-visible name is Videos (or GNOME Videos if differentiation is necessary).

Discovery

The old UI made it particularly hard to consume media from various web sites, as you can see from the screenshot below. It's cramped, we had separate sidebars for search and browse, we didn't show icons for browse, etc.

And here's the new UI, browsing the same source (Apple Trailers).

This is definitely easier to find media. Totem also had a number of specific plugins to find media sources, usually from third-party developers. We don't support those anymore, and if you have been writing such a plugin, you should port them to grilo, now a hard-dependency.

I've also spent some time working on Grilo and its plugins, creating a few new sources along the process.

Amongst the new ones are the Freebox TV plugin, the under-powered Guardian Videos source, and the not-yet-fully-integrated Pocket videos list. Don't forget to check for blocker bugs if you're trying to test those!

Playback

This is also a pretty big upgrade. We now have video-specific menu item, the gear menu, and better looking pop-ups. This matches the design used in GNOME Documents for sliders. It's also better suited for touch: a mouse move will show the OSD for a short time, but a touchscreen tap will show the OSD until you tap it again.

The older version had some features only available in windowed, such as rotation, or zoom, and some we tried to cram into the context menu (subtitle or sound track selection for example). Here, there's no loss of accessibility for features, they're all in the same gear menu, whether fullscreen or windowed.

Bugs, bugs, bugs

With a few valiant testers and designers, we tried to fix a number of bugs. This release doesn't mean Videos is bug-free, far from it, but it's certainly robust and usable enough to make this development release.

There's some theming bugs, as can be seen in that last screenshot's previous/next buttons, there's bugs in grilo and grilo-plugins, and there's bugs in Videos itself.

Do file bugs when you see something amiss, it'll help designers and myself move items from our own TODO lists :)

What's next

A lot :)

You can see some of those in the design wireframes.

"Make available offline" is something I have a great interest in, especially coupled with the Pocket source. Selecting a bunch of items to watch later, on the train, or on the plane.

Better metadata, especially for films and series. This isn't just for films you snarfed from Usenet and torrent sites either. The already existing Rai.tv source has a number of films, and a BBC iPlayer source is planned.

Finally, remote playback, to "throw" videos from your laptop to the TV. Controls should still work, and we'll want to allow browsing through sources when playback is remote.

Notes on development

Half notes, half thanks. As mentioned in the introduction, this release has been some time in the making, but it also comes at a time when we've had the necessary plumbing to make all this possible.

To name but a few, we've made good use of gnome-documents' widgets to list videos, the GtkStack, GtkRevealer and GtkPopover. The GtkSearchBar and GtkSearchEntry widgets are also examples of widgets that moved to GTK+ for Videos' development.

Getting it

Soon in your development distributions, in totem's master git branch, and in GNOME's FTP server.

Stalk^W Following designs, the easy way

If you want to follow all the new designs from the GNOME Design team, including work-in-progress mockups, gathering of relevant art, etc. be sure to subscribe yourself to the pages that interest you in the various sections of the GNOME Wiki.

A nice trick is using our Wiki's notification, with regex support. Head onto your notification settings page, and add those lines to the "Subscribed wiki pages":

GnomeLive:Design*
GnomeLive:GnomeShell/Design*
GnomeLive:GnomeOS/Design*

WebKitGTK+ Hackfest: Day 4

The crema de ojuro took effect. While the effects simmered down, code fixing was still in full flow.

• Philippe finished landing the fullscreen fixes for the <video>
• Xan and Claudio started fixing GNOME 3.4 Epiphany design bugs (on the road towards the Web app design)
• Alex, Martin, Joone and Nayan all looked into Accelerated Compositing. They all owe you, dear reader, blog posts full of nitty gritty details.
• Jon didn't spend the day debugging bizarre browsers crashes
• Wingo punched the air as he figured out a tricky memory allocation issue. He also listened to the Thundercats theme tune, in a loop
• Gustavo and Dan figured out a design for multipart/x-mixed-replace support, as used by some streaming IP cameras, and Gustavo started the implementation
• Nayan showed legendary patience waiting for tourists outside a haberdashery
• Dan committed a number of libsoup related cleanups in WebKitGTK+, including a very impressive minus 200 lines cleanup.

WebKitGTK+ Hackfest: Day 1, Afternoon

After num-num tapas for lunch (and some chocolatey cake), we got back to the agenda, with Jon presenting the design for the Web application, successor (in spirit, and perhaps in code) to Epiphany.

• Andy did the initial work on adding new language features to JavaScriptCore (let and const, as used heavily in gnome-shell)
• Martin and Gustavo worked on a way to automate running the WebKitGTK tests with test fonts, and are working on making all the tests automated, and reproduceable
• Philippe fixed fullscreen support in the HTML5 YouTube player
• Dan fixed the broken security status in Epiphany
• Carlos worked on the WebKit2 support for windowed plugins, and the WebKit side of favicons support
• Philippe, Martin and yours truly discussed sharing of fullscreen media controls (UI and behaviour) between WebKitGTK, Totem and Sushi, as well as a way to make fullscreening smoother.

I hear they didn't finish all the beers for Igalia's 10th anniversary party...

Totem in GNOME 3.0, plans for 3.2

Totem for GNOME 3 is available in the GNOME FTP servers. And now onto GNOME 3.2.

There's a couple of major UI changes planned for Totem 3.2, with designs from the GNOME Design team (and Hylke in particular). These include the removal of the status bar, better fullscreen controls, more contrast when playing movies, etc.

New colours

The changes for contrast are already in Totem itself, and you can grab a 3.2 version of gnome-themes-standard to see the "dark" variant of Totem (or enjoy the screenshot below).

Black Swan, go see it.

New video widget

For the rest of the changes, we needed a video widget that was more flexible than the X-based one we were using. So from Totem 3.2, we'll start using clutter, and clutter-gst.

This means that we'll be able to implement things like OSDs for more than just the fullscreen version, use an indicator in the video directly when buffering for live streams instead of the status bar. It would also allow other useful features, like rotating videos with animations, to preview movies from your phone or camera in landscape mode.

Performance-wise, if you were already using an OpenGL-accelerated desktop, the difference should be minimal, comparing clutter-gst's video sink to an Xv overlay using OpenGL, the major difference being the addition of the videobalance element to the pipeline.

If you don't have OpenGL drivers for your machine, Totem 3.0 will still be maintained, with important bug fixes being backported.

Misc changes

We expect a Grilo plugin making its appearance, which will allow us to focus our bug fixing on the interface parts, rather than having to maintain the code to access various video resources.

We also made changes to the nautilus properties tab, which should make it faster, using Edward's GstDiscoverer.

Colophon

You can start testing the clutter-based Totem, the dark variant, and the faster nautilus properties right now, in the master branch of Totem in GNOME git.

The screen panel

Following on from the region panel, we now have an updated “Screen” panel for the control-center. Richard worked on the initial version (which you can see in older revisions of the control-center for GNOME 3), and I finished hooking it up this week.

Not much to say about this, except that the lock screen timeout preference now changes the underlying preferences for both “on AC” and “on battery”, as well as the idle time (which is used by a number of desktop components like your IM application).

I'm also very glad that we managed to get rid of the brightness levels based on whether on battery or mains power. This usually worked exactly as you didn't want it to. Now, just use your keyboard shortcuts for those instead of hoping to gouge somebody's eyes out every time you changed power source.

See also the design page for more information about the changes made.

Client-Side Window Decorations and misconceptions

This morning, my RSS reader was full of news with links to Mark Shuttleworth's blog about Canonical's idea for windicators.

The problem now is people conflating Canonical's own design decisions (most of which I don't agree with, except for the case of netbook UIs, but that's not the point here) and Client-Side Window Decorations support.

Martin Gräßlin's blog lists a few things that you would lose if we were to use client-side window decorations. Most of them are just wrong:

• Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application: How can you say that when there's no agreements on the implementation yet? Of course Athena widget apps will look different, they already do. As long as the theming and behaviour is known and agreed upon, there's no reasons why it should happen. It's just a bit more complicated because you would have cases where the Window Manager would behave differently from the toolkit. All those are solvable, and old, unmaintained toolkits will not integrate.
• Window Tabbing (KWin specific): Why would that be impossible to implement? You'd just need help from the toolkit to do that.
• Window rules like always show a close button even if the window is not closeable: Working around broken apps? Fix your apps...
• Accessibility features like big border and button sizes for all windows: Certainly not. It would even mean that you wouldn't get a disconnect between application and window manager implementing accessibility features.
• Easily changeable window themes: Why wouldn't they be easily changeable? That's highly dependent on how the theming is implemented in toolkits. I guess it would be the case if you had a half-hearted implementation.
• Shadows which are part of the theme (KWin would not paint shadows for a client-side window-decorated window): Why not? If KWin knows that the application is drawing its own decorations, it could draw the shadows, or you could make the application's toolkit be aware that it needs to draw the shadows. Either way, it's not impossible to implement.

There also doesn't seem to be a list of thing you'd end up winning:

• Tear-free window resizing (when the client is doing the resizing, with a proper resize grip for example)
• Better integration of resizing within applications (say "zooming" when going to fullscreen
• Proper way to do tabs in titlebar, a-la Google Chrome
• Window-as-a-document/object (see the tab interaction part of this Empathy UI review, which would enhance the integration between applications and file managers)

And that's just the things I see myself as winning. There's more technical details on the GNOME Wiki.

Update: Got my knickers in a twist over Client-Side Windows vs. Client-Side Window Decorations, fixed up links and text.