Hey y'all,
This is good stuff that Jonathan and I were just talking about today.
We do need a way to communicate progress. And I really like Justin's
example below. It gets at a few things: 1. completion or near
completion 2. complexity or phases of work (which nicely maps to scope
and iteration planning, incidentally), and 3. it's simple.
Let's do simple for now! To that end I'm wondering if we are at a
point (now that our JIRAs match our design process) where we can do
the below simply and easily on the wiki.
For example, I had a look at the inline edit storycards:
In-line Edit
|
------------------------|
------------------|
------------------|-------------------|------------------------|
Simple i.e. Undo i.e. date picker redo
dropdown Complete
Justin, I know you weren't advocating for this particular solution to
a progress bar, but it has all the features that I was hoping for
weeks ago.
Let's do it -- low cost.
Best,
Jess
On Aug 26, 2008, at 4:10 PM, Justin wrote:
Thank you for the explanation Daphne.
As for the progress and state of development stuff. I have been
using the story boards, story cards and etc. as a means to write
test plans which I would hope would reflect what end goal. As an
example of this, for the inline edit test plan the undo tests have
been a part of it for a while, but marked as not yet implemented.
I don't think it is necessary to file bugs for features which have
not yet been implemented, so it would seem useful to have some way
to monitor which features have been added to a component. I believe
Jess was thinking about this, with the idea of a progress bar.
Keeping with that thought, the progress bar could have a scale of
features as opposed to a percentage.
something like :
|
------------------------|
------------------|------------------|-------------------|
Feature 1 Feature 2 Feature 3 Feature
4 Complete
Where Feature # would be the name of some feature. This would give
an idea of what was complete and what was still on the horizon. An
issue with this maybe that the order listed may differ from the
order features are actually completed, and thus may not give an
accurate representation of what will be implemented next.
It could also just be listed as a set of tasks in a task list on the
wiki. Then the tasks could be ticked off as they are completed.
I'm not too sure what the best approach would be, just throwing out
some thoughts.
thanks
Justin
On 26-Aug-08, at 3:22 PM, Daphne Ogle wrote:
Hi Justin,
That is quite confusing. Sorry about that.
The first example is how we'd like to move forward. The other 2
were how it was supposed to work until we got undo working.
Highlighting (selecting) the entire text when the user clicks in
the box has a higher chance of the user accidentally making an edit
or deleting the existing text so we didn't want that to happen
until undo was implemented. The newest storyboard includes undo
and thus highlighted text (even though it's not implemented)
because Eli is building a prototype for user testing based on it.
It seems to be a difference between the state of implementation and
our end goal. Thoughts on how we can better communicate this? Do
we need a QA space for the release that specifies where development
is as opposed to the end goal?
-Daphne
On Aug 26, 2008, at 6:11 AM, Justin wrote:
In the inline-edit simple text story boards
(http://wiki.fluidproject.org/display/fluid/Inline+Edit+Storyboard+-+Allow+user+to+edit+simple+text
) there are several examples given.
The first case states that when the field enters into edit mode, all
of the text should be selected.
The second case states that the caret should be at the end of the
text.
The third case doesn't mention where the caret or selection should
be
but shows the caret in the middle of the text. This seems to imply
that the caret should be placed where the user clicks on the field
to
put it into edit mode.
I'm not sure which one of these is/should be correct. Are these
supposed to indicate three different ways that the inline edit field
will behave based on context? If that is the case, would it be
confusing for the user, as all three could theoretically be on the
same page?
- Justin
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
