Kontact Touch was the one application that stood out when I tried Plasma Active for the first time. But not in a good way. It looked alien, the interaction was different from the other touch optimized applications and it just felt flawed. Custom buttons and other UI components, slide out context menus, widget based dialogs and a weird bar at the top show clearly that this application was not designed for Plasma Active.
Kontact Touch was written at a time when QtQuick was brand new which explains the custom UI elements that had to be build because there were no standard components. The target was an N900 like device with a small 3.5 ” screen compared to Plasma Actives minimal target of 7 “. It was designed to offer all the features of the desktop version on this small touchscreen and it does, which is its biggest problem.
My (GSoC) job this summer is to make Kontact Touch Mail a true Plasma Active application by reworking the user experience and porting it to Plasma Components in the process.
I believe it is nearly impossible to take all the features of a complex application suite like Kontact and support them equally on a (small) touchscreen without getting a flawed user experience. Therefore I will “reduce” features.
This is more about prioritizing and prominently supporting workflows, that are likely to occur on tablets/mobile devices while other workflows can still be possible but will not be as convenient. Some other features that don’t make sense on a mobile device might also have to go. Take a look at this wiki page if you want to know what’s planed in detail. I guess you want to see how it is going to look so here is a little mockup for you:
mbohlender 
Hi, I like your mockup. Can’t wait to get my hands on a Plasma Active tablet!
Have you seen WebOS’s mail app (HP TouchPad)?
I like how it splits the inteface in three and lets you “expand” the view in an easy way, I find it pretty convenient. You might want to check it out and take a few ideas 🙂
BTW, I can post a few screenshots if you’d like.
Cheers.
I checked out a lot of email clients but never thought about WebOS. Screenshots are not necessary. I found a good video on youtube and it looks interesting. It is similar to my current approach. I also use a column based navigation but I don’t allow stacking/hiding. I can’t tell you more right now. Wait for another blog about the app navigation and how you can get your hands on it. 🙂
That looks so much better, the old one was hardly usable. I tried to do the simple task of deleting a bunch of emails and it was an ordeal of switching views and entering menus. When I saw the original Kontact touch as an example in one of the Plasma active HIG I was thinking it was some sort of sick joke. The new UI looks like anyone could easily get the work done that they need to do while looking good to boot. The preview text as part of the inbox is a great idea. While some may say the features are less, I would say it makes it useable for the workflow you would be using on a tablet. One thing I would love to see is the drag off screen swipe to delete like how the Plasma Active notifier works. If you need to add more features I guess you can add it through SLC or the hold finger menu if you make the menu items configurable in the config KCM most of the “power users” should have less to complain about. So far your mockup is exactly what is needed, I will look forward to see the implemented ui.
What kind of SLC integration is planned? And are there any mockups for the email editor / sending mail?
I thought about swiping gestures for deleting/mark read/…. actions but could not make it work because I use swiping left/right for the overall app navigation on the landscape mode UI.
It might be possible with the portrait mode UI though.
SLC will be used to connect to the other PIM applications. e.g. to create a task or event from an email and probably for tagging and stuff. -> http://community.kde.org/Plasma/Active/mail#SLC
Both is out of scope for GSoC but is definitely planned.
It’s great to read all the positive comments, seems like we’re on the right path!
Instead of just implementing deletion via dragging off the screen, our plan is to allow drag and drop into the views on the left.
This allows deleting as well as marking as unread or as important via d&d, which is even more powerful and flexible as only deleting via swipe.
We’ll have to see how well this works in combination with the horizontally scrolling view, but I’m sure we’ll find a way to distinguish between the two gestures.
Yes! This sounds exactly like the right thing to do (IMHO). I do not like the idea of a swipe to some screen edge to remove emails. I don’t have a tablet, but knowing myself, I am sure that I would be capable of accidentally doing this swipe gesture on an email which should not be removed. Of course I could also do accidentally a swipe to Trash, but then at least there is a visible clue of where the email is going, so I am totally in favour of your approach.
This is good news, and will allow for quick sorting and readings of messages totally in line with the 0 inbox philosophy.
I love the mockup, it’s somehow more natural than the earlier UI. If the interface is good enough, I feel no need for lots of customization, so removal of features is ok. The main thing is to get emails read.
However I personally feel that the mail-pane (list of mail in the current folder) is more important to be visible than the favourite folders, at least while reading an email, so you don’t feel lost. Otherwise the “read next” and “read earlier” buttons could be substituted with some info about the respective emails. I never remember if “newer mail” is to the right or left. Just an idea…
The removal of message grouping by date of whatever is also good. It makes things cleaner.
One more thing, I hope you make the message header scroll up out of the way together with the message itself, not like in firefox where it stays visible all the time.
I’m looking forward to using this one day!
Looks absolutely great!!!
I am not sure if this applies to your idea of UI, but there is one thing I really miss in the current KMail desktop app. If I have opened a mail to read it in its own window, not using the preview, there seems to be no way to get the next message. I have to close the message window and open the next from the list of mails. Would be great to have this possibility in the touch version.
Your mock-up look great.
There will be a smaller version of the mail list on the left side of the mail viewer. It can be used to navigate to a next/previous mail.
Looks great, thanks a bunch for working on this! Mobile KDE PIM needs a lot of love 🙂
So does desktop KDE PIM 😉 But I’m still happy that mobile KDE PIM gets love 🙂
I very much like the new UI!!! Much better than in the first screenshot! It looks much more usable and it is much more pleasant to look at. If you implement all items labeled C and P in the wiki, then I guess that all important features are implemented. E and Z are not really important, except maybe “Add sender to contacts”.
One possible issue I spot in the mockup: the checkboxes for the mails are rather close to the folder selection in the left, so I think it might happen quite often that one accidentally selects a folder on the left when trying to tap on the checkbox.
Maybe adding a bit space there might help or moving the checkboxes to the right edge.
You are absolutely right. There needs to be more space. I am currently working on the overall app navigation only. Refining the single pages will happen after that.
This is coming along rather nicely. 🙂
I guess you are using the standard plasma components, ans thus you can’t do much about it yourself, but for me, there are way too many 3D effects with shadows. Lets count :
The top bar is at the foreground, and the left bar with buttons unactivated is one level below. When a button is activated, it gets incrusted, but still above the list which is at the bottom level. Check boxes are above while the search box in the top bar is incrusted, some coherence here would feel more harmonious. The contextual box come above everything else, adding another layer. All that really feels odd to me.
Looks apart, I really like the overall layout. It is definitely an improvement compared to the previous one. Maybe you could add labels in the contextual box (mark as read, mark as important, delete), as not every icon is straightforward (at least for me), and there is no reason to limit the space it takes.
The improvemnts look awesome and it’s great to hear that Kontact Touch is being updated also internally!
But regarding Kontact Touch there are three issues that stand out for me as an end-user:
1) will the packages finally include WebDAV resources, so I can connect it to ownCloud?
2) how well will it integrate with the underlying (mobile) OS’s UI, notifications etc?
3) will it run (be packaged for) on the Nokia N9?
Again, I very much appreciate the work on the UI and I think it looks tons better!
I am afraid I have only bad news for you:
1) No. I am only working on the mail client. I believe there is a mobile app for ownCloud made by the people of ownCloud.
2) My current plan is to integrate it very tightly into Plasma Active so it will be a native application there. I don’t have enough knowledge about cross (mobile) platform development with Qt to give an informed answer about integration on other platforms.
3) The landscape mode UI is targeted at 7″-10″ screens. I doubt it will work well on a small smartphone screen. The story might be different with a future portrait mode UI. This is planed but out of scope for this summer. My work adds some extra dependencies to Kontact Touch Mail so packaging will require some work. I have no interest in providing packages for the N9 but it is free software so anyone can if (s)he wants to.
I was afraid this will be the answer, yes.
I can very well understand your reasons, but hope that it doesn’t put this cool project into a too small nieche.
Still, I’m looking very much forward to see Kontact Touch be developed further and your KMail Active mockups look great ☺
Though mbohlender has already replied quite clearly from the perspective of his GSoC project, let me gie a reply from a broader Plasma Active perspective:
Regarding 1): Synchronization with ownCloud is on our feature wishlist, and I’ve just recently changed its priority from “exotic” to “buzz”, because ownCloud synchronization is bound to play an important role for Plasma Active in general in the future.
Every commercial mobile platform (and yes, I include Android in this group) has some method to synchronize with a proprietary cloud, so it only comes natural that a Free mobile platform supports synchronization with a Free cloud platform.
So while it will certainly not be part of the GSoC project, PIM data synchronization with ownCloud is pretty likely to happen one day.
Regarding 2) and 3): The result of our current effort will be called KMail Active, not Kontact Touch Mail or KMail Touch, because, as mbohlender said, it is focused on being part of Plasma Active. As such, it will be as much or as little of a “niche” product as Plasma Active as a whole, and that is far from having been decided.
Active applications do not aim to be made available on as many Qt platforms as possible, but to integrate with Plasma Active as well as possible.
Of course that does not keep anyone from packaging it for whatever platform they want to, but it will be clearly noticeable that it was designed from the ground up with Plasma Active in mind.
Thank you for putting this into a broader perspective.
Regarding 1) Akonadi already has a DAV resource that works with ownCloud just fine by now. For other components, I don’t know. What I wonder is why it is not included in Kontact Touch.
Regarding 2) and 3) this makes sense. I still worry about it being a bit of a niche, but then again, that’s how every huge project starts ☺
Does this mean that the Kontact *Touch* project is being abandoned or is it still to early to make that call?
1) In that case, maybe that day may come sooner 😉 We’ll have to see how to integrate it well, though, and it probably still won’t be part of the GSoC project (which is already chock-full of work just to get the most basic features done).
2/3) Indeed. Build it, then they’ll come 😉
About Kontact Touch: It hasn’t really been worked on for quite some time, so unless someone picks it up, I don’t have very high hopes. That doesn’t mean it can’t happen of course. And work on Kontact Touch would benefit from the work on KMail Active as well, of course. mbohlender is contributing improvements to kdepimlibs as part of the GSoC project as well, and anyone working on Kontact Touch could reuse parts of the KMail Active UI, of course.
1) As I said, it’s fully understandable, that there’s not enough time in the GSoC for that … and mbohlender seems to be working very hard already!
Regarding Kontact Touch: I feared as much, but was leaving a small window of hope that I’m wrong and somewhere hidden from plain sight things are progressing. Great to hear that the kdepimlibs are being improved for mobile use 😀