[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Kivio's Use case 1
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2009-12-14 18:27:44
Message-ID: ae32c1ef0912141027i2a9612c4q2f9bdca58a35c0d6 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Dec 11, 2009 at 10:05 PM, Carlos Licea <> wrote:
> On Miércoles 09 Diciembre 2009 02:46:55 Thomas Zander escribió:
> > On Wednesday 9. December 2009 02.22.49 Carlos Licea wrote:
> > > Dear list,
> > > I've been working on the behavior that I, and I assume you'll
> agree,
> > > would like to have for Kivio.
> >
> > Thanks for the work, good to see it moving again :)
> Indeed is good, hopefully I can have something working soon.
>
> > I am a bit worried about the usecase you write about.
> > "Usecase 1: Bob the keyboard guru."
> >
> > Is that honestly a good first (and only) usecase?
> > Creating a piece of graphical software for a guy that hates to touch the
> > mouse? I would really hate to create software for someone that
> essentially
> You're right in that it is the first use case, but I was planning to at
> least
> two more with very mouse-oriented users (either naive or power users).
>
> > will hate everything Krita turns into...
> Well this is Kivio, the user doesn't have to like Krita. Keep in mind that
> not
> everybody is in artist, therefore not everybody has to use Krita.
>
> > Maybe this can be a usecase for a scripting engine ;)
> That's a possibility too, write diagrams in the form of code has crossed my
> mind too. But right now I would prefer to stick with the UI because the
> work
> done there can be shared by other non-programmer users.
>
> > That brings me to the second point, the stuff you wrote is not a usecase.
> > Its a suggested design.
> > There is a huge difference between the two.
> Well I would believe that at least has a little bit of use case, because
> I'm
> describing who I'm designing the application for, instead of just proposing
> a
> workflow.
> In the long run it doesn't matter how I call it (I can change the title if
> you
> insist), but what we do with it. In that sense, would you use it?.
>
> > You wrote about one guy; Bob. Bob the developer.
> > I think there will be very different and opposing usecases too, where a
> > systems architect that hates a keyboard is the main character. Or a
> > mother of 2 that just likes to document her family tree back to the
> 1800s.
> Yes, as I said, more scenarios were coming.
>
> > Using all those usecases KIvio should be designed to work for all of
> them.
> > But your page is really a fully thought out design that works only for
> > Bob. I don't think we want to create Kivio just for Bob, do we?
> Well no, but the same concepts can be applied for mouse-driven users. The
> same
> idea of Kivio handling the details of the diagram, or the semi-automated
> insertion of stencils. I had thought of having small arrows pointing
> outside
> the stencil, if the user clicks it the latest inserted stencil is inserted
> again with a connection. Note that it's consistent with the insertion
> through
> the keyboard arrows.
>
> > I think this page can be turned into a usecase; which means it should
> have
> > a user-intend, a goal, a couple of details how the user likes to work.
> But
> > no implementation suggestions and likely also no mockups.
> The mock ups were just to support the ideas, we can remove them from the
> use
> case and move them to a "Design proposal for the use case 1", or something
> like that.
>
> > 3 examples here; http://wiki.koffice.org/index.php?title=Collaboration
> I'll have a look to them.
> --
> Carlos Licea
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
+1 for every point by Carlos.
One addition for item 3) of Bob's workflow:
"3. In order to insert the next block all what Bob has to do is press the
Down arrow, ..."
If Bob changes his mind after that and decides not to create new block he
presses Up arrow: the cursor moves up and newly-created block is removed as
it doesn't have any text inside.
An addition for mouse port of this workflow:
When mouse cursor moves over a block arrows around the block appear. When
user click on one of them it behaves like he presses an arrow key. When
mouse leaves block area arrows disappear.
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<div class="gmail_quote">On Fri, Dec 11, 2009 at 10:05 PM, Carlos Licea <span \
dir="ltr"><></span> wrote:<br><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;"> On Miércoles 09 Diciembre 2009 02:46:55 Thomas Zander \
escribió:<br> <div class="im">> On Wednesday 9. December 2009 02.22.49 Carlos \
Licea wrote:<br> > > Dear list,<br>
> > I've been working on the behavior that I, and I assume you'll \
agree,<br> > > would like to have for Kivio.<br>
><br>
> Thanks for the work, good to see it moving again :)<br>
</div>Indeed is good, hopefully I can have something working soon.<br>
<div class="im"><br>
> I am a bit worried about the usecase you write about.<br>
> "Usecase 1: Bob the keyboard guru."<br>
><br>
> Is that honestly a good first (and only) usecase?<br>
> Creating a piece of graphical software for a guy that hates to touch the<br>
> mouse? I would really hate to create software for someone that essentially<br>
</div>You're right in that it is the first use case, but I was planning to at \
least<br> two more with very mouse-oriented users (either naive or power users).<br>
<div class="im"><br>
> will hate everything Krita turns into...<br>
</div>Well this is Kivio, the user doesn't have to like Krita. Keep in mind that \
not<br> everybody is in artist, therefore not everybody has to use Krita.<br>
<div class="im"><br>
> Maybe this can be a usecase for a scripting engine ;)<br>
</div>That's a possibility too, write diagrams in the form of code has crossed \
my<br> mind too. But right now I would prefer to stick with the UI because the \
work<br> done there can be shared by other non-programmer users.<br>
<div class="im"><br>
> That brings me to the second point, the stuff you wrote is not a usecase.<br>
> Its a suggested design.<br>
> There is a huge difference between the two.<br>
</div>Well I would believe that at least has a little bit of use case, because \
I'm<br> describing who I'm designing the application for, instead of just \
proposing a<br> workflow.<br>
In the long run it doesn't matter how I call it (I can change the title if \
you<br> insist), but what we do with it. In that sense, would you use it?.<br>
<div class="im"><br>
> You wrote about one guy; Bob. Bob the developer.<br>
> I think there will be very different and opposing usecases too, where a<br>
> systems architect that hates a keyboard is the main character. Or a<br>
> mother of 2 that just likes to document her family tree back to the 1800s.<br>
</div>Yes, as I said, more scenarios were coming.<br>
<div class="im"><br>
> Using all those usecases KIvio should be designed to work for all of them.<br>
> But your page is really a fully thought out design that works only for<br>
> Bob. I don't think we want to create Kivio just for Bob, do we?<br>
</div>Well no, but the same concepts can be applied for mouse-driven users. The \
same<br> idea of Kivio handling the details of the diagram, or the semi-automated<br>
insertion of stencils. I had thought of having small arrows pointing outside<br>
the stencil, if the user clicks it the latest inserted stencil is inserted<br>
again with a connection. Note that it's consistent with the insertion through<br>
the keyboard arrows.<br>
<div class="im"><br>
> I think this page can be turned into a usecase; which means it should have<br>
> a user-intend, a goal, a couple of details how the user likes to work. But<br>
> no implementation suggestions and likely also no mockups.<br>
</div>The mock ups were just to support the ideas, we can remove them from the \
use<br> case and move them to a "Design proposal for the use case 1", or \
something<br> like that.<br>
<div class="im"><br>
> 3 examples here; <a href="http://wiki.koffice.org/index.php?title=Collaboration" \
target="_blank">http://wiki.koffice.org/index.php?title=Collaboration</a><br> \
</div>I'll have a look to them.<br>
--<br>
<font color="#888888">Carlos Licea<br>
</font><div><div></div><div \
class="h5">_______________________________________________<br> koffice-devel mailing \
list<br> <a href="mailto:koffice-devel@kde.org">koffice-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/koffice-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/koffice-devel</a><br> \
</div></div></blockquote></div><br>+1 for every point by Carlos.<br><br>One addition \
for item 3) of Bob's workflow:<br>"3. In order to insert the next block all \
what Bob has to do is press the Down arrow, ..."<br><br>If Bob changes his mind \
after that and decides not to create new block he presses Up arrow: the cursor moves \
up and newly-created block is removed as it doesn't have any text inside.<br> \
<br>An addition for mouse port of this workflow:<br>When mouse cursor moves over a \
block arrows around the block appear. When user click on one of them it behaves like \
he presses an arrow key. When mouse leaves block area arrows disappear.<br \
clear="all"> <br>-- <br>Dmitry Kazakov<br>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic