Sadly I didn’t have much time to blog lately, but luckily today i found some time to do a screencast like the good ol’ times.
What’s shown here is an application that will be pretty central in Plasma Active 3: it’s a file browser (or a Resource browser, it can actualy be about much more than files). Basically this will be the central point to manipulate stuff in Plasma Active.
You can browse all the resources by type, by date, with a timeline representation which can have a zoomed level of detail, so browse by year, by month, by day.
You can select files with a two fingers gesture and then via drag and drop you can move them between the internal storage and a removable device such as a microsd, delete them, or tag them (think about the Google+ circles ui)
The ui is all built using the Plasma QML components, keeping a coherent look&feel with everything else, the general feeling of the ui is aiming to be quite natural, with animated, and real-material feeling surfaces, with a plausible phisical disposition, like the main area that can partly slide in/out to reveal the contents hidden under it, namely the sidebar of controls such as tags and timeline.
But yet is not trying too hard to mock some real object: mobile uis that have things like a wood texture background really go too far and besides being completely incoherent one to another,
The thing we always stressed out in Plasma Active is how the system is designed to fit a whole device spectrum, even if the first two releases are explicitly about tablet devices (and in the near future this is not likely to change 😉
But how? it’s pretty obvious that one user interface doesn’t fit all for sure. Some devices, like mobile phones could share let’s say the 60% of the QML UI written for the tablet, some other, let’s say set top boxes could need something radically different.
The Plasma Active shell is actually something that doesn’t provide any user interface at all, but instead provides some basic features in the logic: manages the user Activities and loads the plugins that will provide the actual user interface, assembled like a LEGO to fit the user experience of a particular form factor.
About user interface plugins: the central parts are Containments and Applets, that are familiar from Plasma Desktop, a new one is a package format used to distribute stand alone QML files sets, and a very important one in the Plasma Active shell is the Home screen.
The Home screen package is a set of qml files that behaves the basic behavior of a Plasma Active shell, such as how Containments are managed, and manages other pieces of user interface such as the activity switcher, the top panel, the application launcher and the recommendation overlay. So by changing this it’s possible to change a lot of the behaviour of the Plasma shell (a particular device could also require a different plugin for the main containment, as they are different between Plasma Desktop and the tablet version with its browser of Nepomuk resources)
To make easier for developers that are interested in new form factors to heavily customize the look and feel of Plasma Active, I’ve put together a wiki page that describes how to proceed writing a new homescreen, and what is the API used in the communication between the shell and the QML part.
Today, Plasma Active Two has been released. It has been a pretty hectic 3 months, a very short period that produced anyways a couple of significant architectural enhancements.
Enhancements that are for both users, that will find more nice features and developers, that will find more nice tools for writing new applications and plugins. A way more complete feature tour can be found here. Here are just a couple of things that are quite importnant to me.
Recommendations: organizing items in activities is even easier: you worked for a while on a file or on a website? a simple button to add it to the activity will be present in the left side panel.
QtComponents: a new widget set to be used in QML applications, that makes very easy porting an application from Harmattan or Symbian.
Bugfixes: we want to make the user experience as smooth as possible 😉
Big props and thanks to everyone that helped out with this release, a group that is growing more and more, from individuals to companies.
One of the biggest new features in Plasma that will be released together KDE Plasma Desktop 4.8 is the new shiny set of QML components, that over the next releases will gradually replace the old simple widgets like pushbuttons lineedits etc.
This is one important step towards a cleaner, easier to use and easier to write user interface, an important step towards Plasma2, where the UI will be completely done in QML, using a fast OpenGL driven scene graph, meaning prettier effects and most important always fast and smooth graphics using more what a modern gpu can actually do.
Here is a video of an example plasmoid (you can find it in the kdeexamples repository, is a good way to learn the api) that shows just a collection of what the available components are.
This is one of the things that are starting to percolate from the work that is being done in Plasma Active and is starting to benefit the desktop as well.
Of course common UI components can’t be really common between the desktop and a mobile device, or between different mobile devices such as tablets and phones, so what about that?
We have a complete series of components targeted to be useful to build widgets for the desktop (as shown in the video above), designed to be as indistinguishable as possible from the old C++ based widgets, so it will mix perfectly in the rest of the desktop. The Device notifier widget is completely rewritten in QML using some of the components for 4.8 and even if it uses 100% new code (modulo the dataengines) it looks and feels exactly the same, there is just a “something” about its smoothness that comes out as a pleasant unexpected thing while it’s used, even if it’s difficult to exactly point the finger at.
So how does the very same widgets gallery plasmoid look when loaded in a Plasma Active two tablet?
The touch specific set of components is used and the plasmoid itself besides using those touch components, adapts itself to the fact of being loaded as a fullscreen application on a tablet and changes its layout accordingly.
Some of those components are pretty universal, especially those without any graphics or input such as Page and PageStack, that manage the life cycle and transitions effect of dynamic pieces of the user interface.
Some components are a bit more specific, but not dramatically different: a button or a text field will look an behave in a very similar way, but for instance we don’t want mouseover effects on a touch screen, and maybe we want the touch area a bit bigger than the actually visible button area for a better grip, but here we still smell at least a partial code sharing.
There are then the ones that we want a flat out different implementation: for instance we want a desktop-themed, independent window for context menus (that is, a QMenu) on the desktop, while we want a more plasma-looking, finger friendly thing on a touchscreen, but still the very same exact api.
We have a series targeted to the current Plasma Active tablet profile uses the 90% of the same code as the desktop version, but everything that needs to be different is different, for instance there we have no mouse over highlight, bigger sizes and hit areas, scrollbars are read only scroll indicators visible only when actually scrolling.
As said by the title of my last post, one of the things that we are trying to do with Active is “humanizing electrons”… make devices behave how people think instead of making people think like the implementation details behave.
To do that, it is necessary to phase out or better, demote and have in a less prominent way some of the concepts that always been with us, but not because they were good, because for tone technical reason or another 20 years ago we were forced to do this way.
Here we aren’t forced to follow the legacy, and the acquired skills that limit what can be changed on the desktop, on this kind of devices we have almost no legacy. (don’t worry, there won’t be a fresh start in the desktop, only continuous evolutionary changes)
Why I have to care what is a “file” and what it isn’t aren’t pieces of information all the same? i couldn’t care less if a contact or a bookmark are stored in a different way than a pdf.
Why I have to organize my things in a weird tree structure, data type that in the human brain simply doesn’t compute?
Why I see arcane names like /usr, /etc and /dev that are simply pointless in my day to day work?
Why if i subdivide my files by project, a file can’t be in two projects unless i do a copy that will go out of sync?
I want to be able to annotate every thing, to be able to remind me what this is about and why is there (informations that would be unwanted in the file itself tough)
Why if the mail application has informations about a contact, this information is buried in this application and everything else can’t have it?
This list could go on for many more points, but i think the concept is clear: while tools like the filesystem are awesome if well used, but aren’t enough anymore for the amount of data nowdays (yes i know, there will always be people that won’t need this, but this is true for any tool in existence).
In Plasma Active we base our graphical representation as much as possible on activities and on what “things” belong to an activity.
We try to make as less difference as possible between what is a file and what it isn’t.
This was only possible because one of the pillars of KDE: Nepomuk.
Nepomuk provides a metadata storage that is abstract enough to do almost everything you please with it. Everything can be a resource: being files, contacts, urls, places or activities. And everything can be related to everything, and here we have things related to activities, or between themselves (who sent to me this file as attachment?)
Sadly, in the desktop is still not used much, apart some pieces of ui to expose its features here and there (good news, getting better here too), but as Plasma Active shows, if the whole UX has its capabilities as the foundation, it can change the way the device is used in a way that surely wouldn’t be possible without it 😉
Another good news, is that while some pieces of Plasma Active are specific of a device UX, some other parts, like the enhancements to the activity manager are shared with the desktop, so should be easy to expect some of those features, like an UI for connection between resources and activities soon in the desktop as well.
Let me talk briefly about one of the goals we have about Plasma Active, of which today’s release of Active One is just a little baby step in this yet important direction.
We think that looking at different devices as isolated worlds, needing completely different “Apps” and UX stacks for each kind of device it’s pretty limiting, and it’s not the way who uses it (aka “humans”;) thinks.
What we believe in, is that computing devices (doesn’t matter if it’s the laptop, a tablet, or something running in a washing machine) should exist in function of helping the people accomplishing the task they want to do, no more, no less, devices shouldn’t be something complex, hard and therefore “harming”, but should just be extensions of the user harm, of the user mind, just tools, and in every situation, the best tool for the best job.
The line between the devices should be as blurred as possible, what we should target on is the task the user wants to accomplish, a task (or workflow, if we want to use a more trendy term;) a task is composed by many actions, many subtasks, and for each one the perfect tool may or may not be the same device, in the same way that may or may not be the same application.
If I take photos in a vacation I need a camera, when I get back I need a big desktop to view, organize and eventually edit the photos, if I want to quickly view them or show them to my friends, I need the device more appropriate compared to where I am: it could be a mobile phone as small as possible, a tablet if possible, or if we are in the living room, a big flat screen TV.
The need of applications that show a familiar, yet device optimized user interface everywhere becomes evident. why was never really done? just a technical detail missing, now we have it; if used well, QML does an amazing job at that kind of “gapeless” customization.
As evident becomes the needs of perfect synchronization, the need of sending not only files, but metadata and pieces of applications across devices, and the need to have interface as natural and “chromeless” as possible.
That’s one of the goals we’re pursuing with Plasma Active. The KDE community can be a leader in this small revolution, a ground that no one of the other mobile offerings ever adventured into, neither open or proprietary.
Last week has been pretty hectic, i can’t really believe that we are so near to the very first release of Plasma Active.
This is the platform that will be the basis of the pursuit of our vision about the device spectrum, is the platform we will use to build not only a very good user interface for tablets, but to go from there colonizing many other kind of devices.
This has been kind of a mirage for me from the last (two? three already?) years, we are playing with this concept and playing around a workspace for mobile devices since years.. there was plasma-mid, a first prototype designed to run on devices like the venerable n810, that was around 2008.
Then we worked on the first workspace of the KDE project that was not aimed to a strictly traditional desktop machine, KDE Plasma Netbook.
We had to go deeper..
At Tokamak4, we started a new shell, this time oriented towards mobile devices, way more customizable than the previous ones, because it was more heavily based on QML. as a demo state it was made run on cell phones and tablet devices, it learned how to make phone calls, it had many user interfaces looking completely different each other.
Fast forward to the beginning of this year, also thanks to basysKom that seen the potential in it, this shell was improved and merged with a really interesting project: Contour.
It aims to bring some really innovative concept to device UX: deeper use of activities, gathering of usage statistics for useful recommendations (watch out for Plasma Active Two 😉 and in general diminish the importance of the “App” blending all in an uniform seamless “Workflow”.
Plasma Active was born, and became something way bigger than it was expected in the beginning. Bigger than just a tablet interface, that is the “visible” part that will be released tomorrow.
Bigger than just the source code that will be released: it’s a new way to approach to the development of components (not even saying “apps” anymore;) for an user experience composed of more than a single device. It’s the first really fully open stack for devices, bringing an open (as in open process, not only code) system in the closest sector of computing to date.
It’s also the manifest of commitment and reliability of an opensource community: we said over half a year ago that the release was going to be 9/10/11, and 9/10/11 is, showing how serious our intentions are.
What a ride has been, and what a ride will be from here, gonna be fun 😀
An important part of the Plasma Active Contour user interface is the connection between the objects that i can view with my tablet, like images, webpages, and documents with the current activity, to help to organize your work and fun.
I already wrote here about the activity screen: the main Contour workspace will show everything that is related to the activity and is the natural evolution of the Plasma Desktop activities (that will evolve in this direction as well as the integration with applications becomes deeper;)
The screencast below shows the usage in practiche of the concept I’m going to explain in the next paragraphs: Share Like Connect (SLC).
It also shows towards the end the progress of the Active image viewer application, a touch friendly image viewer that deeply integrates with the Contour UI in terms of Look&feel and technology, since uses Nepomuk as metadata storage backend and supports SLC
So we have an interesting UI problem: easily buildthis relationship between objects and activities with just one click (or so;) without having to navigate trough an over complicated user interface.
So, we have a simply search interface right into the workspace, it works well for many use cases and is really simple, but what if I’m browsing a website and want to add exactly that website in my activity? (or a photo I’m viewing, or a document I’m working on Calligra…)
Copy the url of the website, go to the workspace and paste it somewhere? a bit overkill, isn’t it?
Have some UI in the web browser that lets me add the current site to the activity? Definitely better, but we would end up with a different implementation, and a slightly different UI for each application.. can we avoid that?
We also noticed how similar this problem was to another one: is very common that while I’m viewing something i want to share it with someone in some way: I could want to upload on flickr a photo that I’ve just taken, or I may want to send via email to someone a PDF that I’m reading right now.
On the desktop the current workflow is to leave your current application, go to the web broser or email client, search the file again and upload/send it.
On mobile platforms things looks a bit more convenient: many applications have built in the possibility to share the currently open file to some services, but each application has its own implementation, often having a slightly different ui to do the same thing, or support to different web services, maybe because the developers of the application wanted to push their own services (a random example starting with G comes to mind 😉
So, get back to the problem of connecting the current open “thing” to the current activity (avoiding “file” by purpose, since could be something that is not a file at all, like an URL) is similar to wanting to share this same thing with someone, or rate it, or add a tag, tweet it, like on Facebook…
Since we already log what is the currently open object (for how long, how often etc..) to be able to log history and construct recommendations, the external workspace knows this information.
We can provide actions in a global menu in the top panel to perform those tasks, divided under 3 menus: Share (upload on web services, send by email), Like, (rating, bookmarks, “like” on web services), Connect (connect to the current activity, to an event in the calendar, etc).
A first version of this global menu will be available with the first release of Plasma Active, and will eventually make its way to Plasma Desktop as well.