"Big picture" design one release cycle ahead?

[Inge Wallin]

On Saturday, October 27, 2012 10:55:37 Björn Balazs wrote:
> Hi Thomas, all,
> 
> to stress your words: I think best practice for doing usability work
> in an Agile Context is to extent the current sprint in both
> directions. Not only the next sprint needs to be prepared, also the
> results of the last sprint need to be evaluated in order to foster
> the idea of continuous improvement of the team and the results.
> 
> So absolutely agreeing with what you suggest Thomas, I would like to
> bring in the idea of even doing the same thing for the smaller
> sprints on our way to the next major release.
> 
> Let's get in touch with our users - try to understand what is working
> good and where improvements are needed, as part of the preparation of
> the next sprint. And after the sprint, let's again talk to them and
> see if we managed to substantially improve the perceived quality.

I think herein lies the problem.  Who are the users? Or rather: Who are the 
intended users?

I think we can all agree that our[1] *current* users are hackers, mostly with 
a KDE background. That demography is not very big and cannot be the full 
intended audience.  :-) 

So who are the intended users?  After some deep analysis (i.e. standing in my 
shower thinking about the problem) I have come up with 3 possible groups who 
might be more interested in Plasma Active than the average person:

1. Tinkerers like the people who buy and hack the Raspberry Pie. This is an 
extension of our current user base. Being able to hack a tablet OS is probably 
very exciting to these people and Plasma Active is about the only viable 
solution out there.

2. The control industry. I think that many companies will be very interested 
in having full control over their solution. I also think that many control 
applications will turn to tablets because they can give a good interactive 
feedback to the end user.

3. Educational organizations. Here I think of both public ones and in-house 
ones inside larger organizations. The interesting part here is probably not PA 
in itself, but the larger system with a free add-on server. The current 
solutions with IOS, Android and Windows RT all have problems with content 
distribution going through a central server controlled by somebody else.

So there you have it. What I think we can forget for the foreseeable future is 
the normal consumer going out and buying a Plasma Active based tablet.

So... I bet that these groups have very different needs and priorities. My 
personal interest lies with category 3, but I also think that this group needs 
the most mature system. And I know that Aaron likes to say that "we can't play 
the number-of-apps game" but I think that the lack of apps for will be seen as 
a big problem for this group even though it's not strictly a problem for their 
intended use in itself.

I intentionally put the groups in the order I did because I think that the 
needs for group k+1 is a superset of the needs of group k. Maybe a viable plan 
would be to make PA4 target group 1, then expand the scope of work to the 
needs of group 2 for PA5 and so on?

It's interesting though to see that the suggested focus for PA4 is books and 
reading. I have the feeling that this suggestion was made before any analysis 
was done about the intended users. So is books and reading a priority for 
group 1?  Luckily I think it is.  :)

Finally, to think a little more about the big picture - and with this I mean 
the whole eco system, not just the software on the tablet...

It is my firm belief that for PA to become a sustainable success we need to 
have commercial interest. This includes both paid developers and real-world 
solutions based on PA. But first we need hardware. Fortunately I hear that 
this is going to be covered RSN. So we can concentrate on the software.

This means that we should try to get group 2 on board as soon as possible. And 
for the long term I don't think we should dismiss compatibility with Android 
out of hand.

> We would probably need dot releases after each sprint (and hence have
> a shippable product after each sprint) and we would need to implement
> some way of talking to the users (best would probably be directly
> through the product).
> 
> This would also allow us to ask relevant questions on our way to a
> task centric approach.
> 
> What do you guys think?

Well, see above.  Sorry for the long rant, but this is a time for decisions 
and we need to look at the even bigger picture outside our software 
development.

	-Inge

> Cheers,
> Björn

[1] I include myself here even though I haven't hacked much on Plasma Active 
because I have some Plans(tm)...  


> Am Freitag, 26. Oktober 2012, 13:21:49 schrieb Thomas Pfeiffer:
>> Hey folks,
>> I have a suggestion:
>> I fully support Aaron's idea of small concentrated effort sprints
>
>with
> 
>> integrated design and development, which comes pretty close to
>
>agile
> 
>> development. However, product managers in the industry have found
>
>that such
> 
>> short design cycles do not work well for all kinds of design. They
> 
>work
> 
>> well for small features/improvements, but for introducing larger
> changes or
> 
>> completely new concepts, longer research/strategy/design phases
> work
> 
>> better.
>> 
>> 
>> 
>> 
>> One of these big changes for me is fleshing out the general concept of 
>> task-driven design for PA. Since the big picture won't be implemented in 
PA4
>> 
>> anyway (we already got our hands full with small improvements/polish), I
>> think it would make sense to use this release cycle to work design-wise on
>> the big picture of a task-driven system parallel to designing the detailed
>> improvements for PA4 in each focus sprint.
>>
>> The big disadvantage is of course that design capacity is split between the
>> two, but i think this is pretty much unavoidable since designing for a new
>> metaphor requires more then just a few weeks and we probably don't want to
>> have a full release without any actual development. In case of insufficient
>> design capacity for both, the focus sprints would always have higher 
>> priority, of course. The biggest advantage to me is that ideally we have a 
>> broad concept for task-driven design ready by the end of the PA4 cycle and 
>> can implement the details for PA5 if we wish to do so.
>>
>> So what do you guys think? Is the path to task-driven design worth putting
> 
>> some effort into it ahead of time?
>> 
>> Cheers,
>> Thomas