FE Design JIRA structure

[James William Yoon]

Hey folks,

I had a bit of trouble fitting the tasks for spatial mapping (e.g.,
getting feedback on our spatial map scenarios and storyboards) using
this structure. The solution in our spatial mapping scenarios cut
across the different spaces (floor, room, and object levels,
specifically), so it wasn't possible to position the task under just
one of them.

We could try slicing them in a different way--maybe the same way we
proposed for conceptual mapping (a spatial map with museum content vs.
a spatial map with user-generated content; authoritative content vs.
visitor footprints).

This problem might also just be an exception, since the scenarios we
have are very broad. In the future, if we focus on more modular
visitor experiences (what a visitor might do room-to-room,
zone-to-zone, and object-to-object), the problem would be rendered
moot.

Any suggestions, comments, or ideas?

Cheers,
James

On Fri, Jul 3, 2009 at 10:39 AM, James William
Yoon<james.yoon at utoronto.ca> wrote:
> Thanks, Jess!
>
> I'll add a bit of explanation to the underlying structure that Jess laid out:
>
> Mobile:
> We're approaching this space as transformations of data for the
> various different devices. Thus, we've laid out our task structure
> first by the device we're transforming for (iPhone, Android, etc.),
> then by the content type (e.g., artifact data, spatial map, conceptual
> map, etc.).
>
> Spatial mapping:
> This is being broken down by the granularity of location. That is, wrt
> to maps, what options and avenues will we offer at the floor level,
> the room level, the zone and sub-zone level (i.e., proximity to a
> group or subgroup of artifacts), and the individual object level?
>
> Conceptual mapping:
> We've structured this by the type of data. Specifically: 1) museum
> generated data ("authoritative-data"), 2) visitor generated data
> ("visitor-tagged-data"), and 3) data based on a string of interactions
> throughout the space ("time-data"). By "authoritative-data", we mean
> things like date, place of origin, authorship/creator of the artifact,
> etc.; and by "visitor-tagged-data", we mean things like that the
> descriptive keyword tagging of artifacts, interest (e.g., "favourited"
> artifacts), etc..
>
> You could imagine a second-tier slicing of conceptual mapping
> involving the visual representation of the data itself. For instance,
> a task could be "conceptual mapping -> authoritative-data: timeline
> visualization: <details of work task here>". (does this make sense to
> do?)
>
> Also, to emphasize what Jess said: this breakdown is for planning
> purposes to organize and structure out our tasks in Jira. The spaces
> and activities shouldn't be seen as independent of each other--the
> opposite is true. One can easily imagine that our spatial mapping
> solution will involve crossing over between the various levels of
> spatial granularity (floor, room, proximity, object). Similarly, one
> imagine the three "components" themselves will spill over into each
> other: conceptual maps crossing into spatial maps, work from
> conceptual maps being translated into the mobile device, etc.
>
> Cheers,
> James
>
> On Fri, Jul 3, 2009 at 7:50 AM, Jess Mitchell<jess at jessmitchell.com> wrote:
>> Below is an attempt to organize the work that the designers are getting into
>> JIRA -- as a way to structure their "iterations" of work.
>> James and I just had an impromptu brainstorm about how to structure the work
>> and came up with this as a recommendation:
>>
>> component field in JIRA  summary description structure
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> Mobile
>> iPhone: artifact data: <details of work task here> [Shared with
>> FirstinitialLastinitial]
>> as an example, see: http://issues.fluidproject.org/browse/FLUID-2973
>> iPhone: spatial data: <details of work task here> [Shared with FILI]
>> iPhone: conceptual data: <details of work task here> [Shared with FILI]
>> Android: artifact data: <details of work task here> [Shared with FILI]
>> and so on...
>> (we are still doing early thinking in the following two areas, so the
>> summary description structure is drafty)
>> Spatial Mapping
>> object-based: tech: <details of work task here> [Shared with FILI]
>> room-based: tech: <details of work task here> [Shared with FILI]
>> proximity-based: tech: <details of work task here> [Shared with FILI]
>> (this is the one where we have the most thinking to do)...
>> Conceptual Mapping
>> authoritative-data:
>> visitor-tagged-data:
>> time-data:
>> The goal is to have enough of a shared vocabulary that we can all begin to
>> put our tasks into JIRA.  Our thinking *will* evolve and we will change the
>> vocabulary to make sense to us.  The above represents what we're thinking
>> now and want to use for our iteration02 planning in JIRA.  We aren't locked
>> in to doing things this way, so we can adjust to make JIRA work for us.
>> Feedback, comments, questions?
>>
>> Best,
>> Jess
>> ~~~~~~~~~~~~~~~~~~~~~~
>> Jess Mitchell
>> Boston, MA, USA
>> Project Manager / Fluid Project
>> jess at jessmitchell.com
>> / w / 617.326.7753  / c / 919.599.5378
>> jabber: jessmitchell at gmail.com
>> http://www.fluidproject.org
>> ~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>>
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>
>>
>