[Kde-pim] GSOC Kontact Touch

[Thomas Pfeiffer]

On 26.02.2013 21:27, Aaron J. Seigo wrote:
>> Well, we already have tab-like interfaces both in Files and in the Add Items
>> dialog, and they work well there.
>
> i'd actually like to see them go away in Add Items, replaced with a list down
> the left side ala Add Ons, Files, etc.. i don't know of a reasonable
> replacement for the ones in Files, unfortunately.

I don't think the specific column-based design of Add Ons makes sense in 
the Add Items dialog since we only have two levels, but I don't really 
care a lot whether the categories are stacked horizontally or 
vertically. The benefit of a vertical list would be that it has less 
problems with lots of categories, of course.
I think for cases like in Files, the tabs are okay since they offer 
different perspectives on selection and the number of tabs can be limited.
I don't think tabs are a bad concept in general. They just got a bad 
name when people tried to use them for _everything_, especially dynamic 
tabs ("Hey, it works for browsers, why shouldn't it work for my 
application?"). For a limited, fixed number of sets of controls which 
can be clearly categorized, they work pretty well imho.

>> They are not the solution to everything,
>> though, of course.
>
> indeed; nothing is :)
>
>>> but yes, the workflow needs re-examining. we have 3 sets of tools at our
>>> disposal to achieve this and keep the Plasma Active design harmony:
>>>
>>> * column based categorized lists (Add Ons, News, Settings)
>>> * side drawers (Files, okular active)
>>> * in-line UI (page stack and friends)
>>>
>>> i don't think there will be a single silver bullet for all the ways
>>> dialogs
>>> and drawers are currently used in Kontact Touch, but mapping out the
>>> overall workflow using the above three approaches should be possible and
>>> result in improvements.
>>
>> I think this project will be crucial to find what can be done with the UI
>> patterns we already have, and where we need new ones.
>
> +1
>
>> And to avoid creating new patterns where it's not necessary, I'd like to co-
>> mentor the project (as already stated in my previous mail).
>
> yeah, i think that would be immensely helpful.

Great! Now we just need to find a mentor for the GSoC project. Marco 
wrote that it would be nice to get someone from PIM as mentor (he didn't 
CC the kdepim list in his mail though, so they don't know it yet). 
Should we ask them if one of them can mentor?