Looking past the irony that QML will be available for all platforms but WP8 in the short-term, and Nokias previous involvement in the development of QML, it is nice to see the platforms being created.
The last in the row is Ubuntu Phone, others are Jolla’s Sailfish, RIM’s BB10 Cascades, KDE’s Plasma and Nokia’s Components for Harmattan and Symbian. Qt seem to unlock the future UIs for devices.
What is striking is the interaction patterns being established. Nokia Swipe, Sailfish as well as Ubuntu Phone seems to rely heavily on swiping from the sides of the screen. This is, in my experience, the key to a truly one-handed device.
Using Android, you are constantly forced to hold the device in awkward angles or use two hands to reach the home button, be it physical or on-screen. Swiping with the thumb is always possible when using one hand (as long as you have an opposable thumbs), while the two-handed user can swipe using the index finger without feeling hindered by the interface.
From a development perspective, it is interesting to see how the different QML Components are shaped. Ubuntu seems to have some interesting ideas for theming going on, and the other platforms have their own strong points.
One interesting comparison is to look at the API for a single component. Comparing the CheckBox elements of Ubuntu Phone, BB10, Harmattan, Symbian and Plasma gives the following API (only looking at the properties and signals that I regard as relevant to the comparison in question).
Properties
- text (BB10, Symbian, Harmattan, Plasma)
- checked (BB10, Symbian, Harmattan, Ubuntu Phone, Plasma)
- enabled (BB10, Harmattan)
- pressed (Symbian, Harmattan, Ubuntu Phone, Plasma)
- hovered (Ubuntu Phone)
Signals
- onCheckedChanged (BB10, Symbian, Harmattan, Ubuntu Phone, Plasma)
- onClicked (Symbian, Harmattan, Ubuntu Phone, Plasma)
- onPressAndHold (Ubuntu Phone)
Where does this leave us? For all platforms, one can use the checked property and its onCheckedChanged signal to act. The rest is in up in the air. Ubuntu Phone seems to split the text from the checkbox while the others keep them together. The enabled property is missing from most platforms. Here, even Symbian and Harmattan, both from Nokia, seems to differ.
Still, as the concepts seems similar, the work to create a cross-platform set of components wrapping the components of each platform should not be an impossible task (looking at checkboxes only, that is). Hopefully the end result will not be a too fragmented API landscape and the involved parties will work towards a common setup of basic properties and signals.
Either way, I’m happy seeing that 2012 was a bad year, 2013 looks very exciting. Seeing all these innovative phone user interfaces being created with QtQuick, I’m happy to work at a company innovating in the automotive space using the same technology.
Disclamer! These findings are based on the API docs only. Feel free to correct me by commenting.
With my limited experience with swiping from the side of the screen, it seems that cases (which are thick and often go right up near the edge of the screen) often interfere with it.
What is this “hold the device in awkward angles” you’re talking about? This must be about ancient Android phones :) The last few versions standardize on “soft buttons”, it’s easy to reach Home cause it’s always forever in the bottom middle of the screen.
Actually, I use a Samsung Galaxy S3 and find it very awkward… as does my wife’s HTC hero…
Same awkward on the Galaxy Tab. My hand holding that tablet is usually in the upper half and I need either the second hand and move it down to switch between apps/reach the home screen or need to indeed change the angle / the way how I hold the tablet. The hand holding that device is just never near the bottom. With swipe I could do that with the same hand holding that tablet without changing any position just with the thumb like I do on the N9 and the Playbook. Both work well with one hand even beyond a single application.
I think the “PressAndHold” Feature is also available at Harmattan. All in all your idea is great, it’s nice to build your own QML Components on the other side it would be very nice for porting apps, to have the same “API” for all components. I think also ListView’s should be the same, because they are very often used. Also TextField/TextInput elements! :)
GB
on the “enabled” property: I think all of them have it. On BB10 it is inherited from bb:cascasdes:Control, on anything using QtQuick1 (e.g. Plasma) it is inherited from QGraphicsObject, on anything using QtQuick2 it is inherited from QQuickItem
GB, Kevin, thanks for point out these missing properties/signals!
I’m not that feared of fragmented API space, because if you have done your homework (you’ve written your business logic in C++), creating an interface on top should be as easy as pie. Initiatives to standardize this are welcome, but I doubt it and I’d be already very happy if I could reuse the business logic throughout different platforms. Thinking Qt is already running on MeeGo, Symbian, Android, Sailfish, Ubuntu, Windows, OS X, Desktop linux and will soon run on iOS makes me a happy developer!
@Nejc
An user-interface can be a complex thing. You can go with pure QML and then t all works fine on any platform. Using SystemPalette also platform coloring works in most cases but for proper pkatform-integration, like Ubuntu’s styling concept or just hoe a TextInput looks like, you need to write one UI per platform or have basic elements like Button, CheckBox and TextInput that wrap to the platform components.
As Qt-developer I am lazy. I am used to recompile and be fine. It would be great to reach the same level including proper platform integration with minimum additional work or code on my side means in my apps. Just a QML-API I can use and Qt does then handle all the platform-integration, styling and stuff for me. I just not like to need to care about that. QWidget’s like :)
Good point on defining some base level of compatibility. I additionally would suggest some enhancements in the content to avoid confusions in the general public. QML is just a language. Most people use Qt Quick on top of it. BlackBerry 10 provides the Cascades framework running on top of QML and is not using Qt Quick. Cascades include high-level UI components, like Buttons (not available in Qt Quick) and some other items and elements comparable to those in Qt Quick. The fact that Qt Quick provides only low-level primitives is the key motivation for many parties in different industries for starting own developments. I’m very sure the actual list is much longer those you mention. Those you mention just express their intends in public and so get cited. Digia as a new owner of Qt should drive any upcoming unification works and additionally improve Qt documentation and terminology (e.g. what is the actual difference between “item” and “element”) to avoid confusions.
@Vladimir I know that BB10 is the “odd bird” in this setting, and I know that I’m not intimately familiar with the platform. I guess the tradeoffs made at RIM give a better platform in some sense, while it is not a pure QtQuick solution.
As for who should the driving the unification, I believe that it is in Digia’s interest. However, as Qt is an open source platform run by the Qt Project, I believe that all users of Qt are jointly responsible for this in some sense. This implies that if RIM believes that it can gain from such a unification, e.g. get more apps for the platform, RIM can drive such a unification as well. The same goes for all the other parties: Canonical, Jolla, Mer, KDE, and so on.
Personally, I can see where this would be hard to realize. Language limitations in QML, as well as fundamental differences between the platforms are factors that can play a part in this. Still, I do believe that the cross platform abilities is one, of not *the*, core value of Qt. Providing something similar to the classic widgets, i.e. a set of components that can be hinted to behave correctly on all platforms (my definition of hint: a setting that only applies where applicable). It would still require validation on each platform, and probably tweaks, but it would provide a method for tweaking, and also a method for providing a tweakable API.