Wednesday, April 13, 2011

Plasma Active: Active Apps

Foreword



This is the third in a series of five daily blog entries covering the various tracks in the Plasma Active initiative. Today we'll be looking at a concept we call "Active Apps". Where Plasma Quick is mostly (though not entirely) about infrastructure and Contour is a project with a Plan(tm), Active Apps is where we are really looking to the broader community of developers, designers and dreamers to help Plasma Active achieve its full potential.



Go Go Gadget Active Apps!



Having an operating system that boots into a shell which provides a basic interface to the system is a good start, but it isn't enough to provide a full, exciting experience.

People want all sorts of functionality on their devices, ranging from getting directions from a map to reading eBooks to playing games to .. and on and on. Whether it's a tablet, a set top box, a laptop, a phone .. it doesn't matter these days: we expect similar (if scaled) access to functionality across the device spectrum. Plasma Active needs to meet these needs.

That's a tall order for the relatively small group people already working very busily on the other tracks of Plasma Active. Fortunately, we're just the tip of the iceberg that we call the KDE community.

If we look through the catalog of KDE software titles, we find mapping software, and office suite, messaging apps, document viewers, games .. and on and on. Many of these projects are working on touch friendly versions for use on devices such as tablets and phones, but there is isn't much in the way of coordination between the projects or a clear path to accessing the results in an installable operating system image in a timely fashion. Other projects are wanting to add more device form factors to their targets, but aren't sure how to proceed exactly. Still others may be simply waiting for an open ecosystem to emerge to start working on that application they've been dreaming about for months or years now.

The Active Apps program will provide a collaboration and support zone for all of those working towards the common goal of making an amazing device experience. Combined with practical testing and deployment infrastructure, we hope to provide fertile soil for existing and new mobile-focused projects.

Of course, in a perfect world we'd be able put all the existing KDE/Qt software on top of Plasma Active right now, walk away with a smile on our face and call it a great day for consumer devices. This isn't a perfect world, and there are things that prevent us from doing that.

Giving Definition to "Active App"



We can divide KDE apps into one of three general categories:

  1. Touch friendly, stable apps with a device-appropriate resource footprint

  2. Apps that work Ok with touch, but have some remaining issues such as relying on menubars or dialogs with lots of little widgets

  3. Apps that are essentially unusable on the devices Plasma Active targets due to a mix of resource requirements, touch friendliness, completeness, etc.



We are looking for applications in the first category for inclusion in Plasma Active. A definition for what makes an app "Active" was started to allow us to identify candidate applications and give developers working on them something to aim for. In general, Active Apps should be touch friendly, power friendly, perform well, stable, designed in a way to cover as wide an arc of the device spectrum as possible and integrate well with the overall platform.

The Active App definition is, however, in a very early state right now. It needs to mature into something we can all use as a clear guide to creating Active Apps. Reaching a "first release" of the definition is therefore the final goal of this track.

To accomplish that, we need the input and involvement from as many people working on Qt and/or KDE based software who are targeting consumer devices. That participation will help turn the definition into something clear, consistent, robust and reflective of the real world. As such, the definition will remain an open, living document for the duration of the Active Apps track.

The Path We Build Together



If you look at the diagram of the Active Apps track at the start of this entry, you'll notice that there are a lot of milestones on the route. Each "stop" on the route represents an announcement of a new Active App inclusion. That will make at least one new Active App every two weeks.

Contour is our first "Active App", and we are also talking with the Marble, Caligra, Kontact and Rekonq teams (and probably others by the time you read this :). We still have plenty of functionality gaps to address and a lot of stops on the track left open, however.

So if you are working on an application that you'd like to see on consumer devices (tablets, set top boxes, etc.) that fits or will fit the Active App goals, we would like to start working with you and your project for inclusion as an Active App. This is perhaps one of the easiest and most effective ways for software developers with existing projects to make an impact on Plasma Active and its directions.

Approximately one week after each new Active App announcement happens, a new installable image (something I'll be talking about in more detail tomorrow) will be available with the current state of that application included. This means that not only will Plasma Active grow every fortnight with the fruits of Contour and Plasma Quick, but as a user or developer you will be able to watch the suite of included applications bloom with each spin of the operating system.

How You Can Get Involved



If you are working on an application or Plasmoid that you'd like to see become an Active App, if you'd like to help define what "Active App" means and/or if you'd like to help test (or just enjoy watching it grow), here's how to join the Plasma Active team and start participating:

  • Read over the Active App definition page. Bookmark it, subscribe to changes by hitting the "Watch" tab, be ready to revisit it from time to time as it grows and is refined.

  • Join us on the active at kde.org mailing list and/or in #active on irc.freenode.net. Join the conversation, challenge the existing ideas and add new ones to the discussion.

  • Tell us about your application and how you see it fitting into Plasma Active, and we'll all work together to schedule its inclusion and work together on making it more "Active".



If you are unsure if your app is "ready" for Plasma Active, it won't hurt to ask for feedback and start a discussion. We have many months, several sprints and conferences and a major KDE release day in the summer between now and the first Plasma Active release. During that time work on making your app "more Active" can happen. There will also be more development cycles to follow this one that wraps up in the fall. In other words, don't sit on the fence pondering ... jump on the train today!

4 comments:

Nuno Bento said...

Another blog entry, another great piece of insight into Plasma Active. Thanks Aaron ;)

Allow me to leave here a list of some KDE applications that I'd like to see in Active:
- PDF/Document viewer (e.g. Okular)
- Note Taker/Organizer (e.g. BasKet)
- Multimedia player
- IM application
(No personal preference regarding the last 2)

Naproxeno said...

First of all, I really like the outlook of the whole Plasma Active project. I really, really, do.

I have a slightly offtopic question. One thing I particularly like about Android is how the Activities and Intents system works by making applications modular, so that one application can use a part of another to complete a task. For example, if I have to select a contact anywhere I can do it using the standard phonebook or with a third party application which includes that functionality, no matter the application which needs that data.

In "standard" KDE applications, we have the common file picker, the print dialog and MIME types to launch other applications but, apart from those, applications are more or less isolated, as far as I know.

The only counter-example I can think of right now is digiKam and KolouPaint calling an external program to import scanned images.

It would be nice if in Plasma Active, whenever the user needs to pick a contact, a standard dialog would be shown, even if the request came from an third party KDE application outside KDE PIM, or that if I want to attach a photo somewhere, the application could delegate that task to the camera application instead of merely launching a camera application for me, leaving me to take the photo, saving it somewhere I should to remember and then having to pick that file in the original application.

This last use case is more or less the same as scanning a document in an image editor on the desktop but with a use case that applies only in a tablet or smartphone environment, devices which usually have a camera.

Given that Plasma Active is just starting, are there any plans on how to deal with this?

I know my explanation is a bit fuzzy but at least I hope you understand my concern.

Thank you!

Justin said...

Thanks for this informative series of posts. The vision is inspiring and the enthusiam contagious...

Keep up the great work and clear communication!

Fri13 said...

I hope the "active" is done so that user can just click in system settings "Touch screen friendly" option ON and then GUI is set (old one saved of course) for touch screens:
- Toolbars gets by default configured icon size
- menubars are hided with global Ctrl+M function (Ctrl+M function really need to be moved to kdelibs so all KDE apps support it!)
- virtual keyboard is added to panel
- some new visual buttons to panel are added to active some KWin effects like present+desktop grid
- window decoration are hided (default)
- Panel is resized bigger
- All windows are in fullscreen mode by default (if not user want to manage windows by self)
- Oxygen style gets 2-3 times bigger buttons and scrollbars/sliders.
- Touch gestures are presented with multitouch support (change virtual desktop/activity, show all windows (present + grid), close/minimize window