I like it! Let's do it!
Inline edit is that weird bird where we have a family of functionality
so perhaps it actually gets a family of status bars: simple text,
date picker, dropdown, editible link, etc. Each of those could then
have a status bar for the features within it.
Thinking aloud a bit about how we might take advantage of jira and
confluence for this. If we put all story cards in jira (we haven't
been putting in story cards that aren't on the radar to be scheduled
work) and they are at the feature level of granularity, we could
easily see what is and isn't complete.
-Daphne
On Aug 26, 2008, at 3:22 PM, Jess Mitchell wrote:
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
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
