Feature requests for Sakai OAE

[N. Matthijs]

Hi everyone,

Now that Sakai OAE is entering a phase with a lot more deployments
and users using OAE, we've seen an increase of feature requests
and suggestions for improvements in JIRA.

In this instance, I'm referring to a feature request as a user-facing
change or improvement, which most likely needs some design
attention as well. An example of such a feature request would be
SAKIII-3609 [1].

However, bringing them in via JIRA is probably not the best
way to go about this. They're mixed in between a ton of other
JIRA tickets, so it's very easy for them to get lost. I've been
keeping a list of requests in a document, but it's not the best
way to do this and a lot of them don't make it to design. Putting
them in JIRA also makes it hard to prioritize them and get people
to weigh in as to why they are important. However, up until now
there hasn't been a better way to raise these, and I really don't
want these to get lost.

Therefore, I'd like to suggest that we try and use [2] for submitting
ideas for improvements and new features. This allows people to
submit ideas and vote on existing ideas. This should make it easier
for design to get a better idea of what the most critical issues are.
It's not the best or the prettiest system, but it is free and it is very
easy to get the data back out if we have to, so I think it's worth a
try.

I've also added a link to this into the OAE footer (will be in the v1.0.1
release). This will allow end users to make suggestions and vote as well,
and being able to collect this from across the community should be very
powerful.

I've already put some of the requests for new features that were
currently in JIRA into this system.

Suggestions for technical improvements or areas to make configurable
are definitely still fine to go into JIRA. An example of such a ticket would
be SAKIII-1973 [2]

[1] https://jira.sakaiproject.org/browse/SAKIII-3609
[2] http://sakaioae.idea.informer.com/
[3] https://jira.sakaiproject.org/browse/SAKIII-1973

Kind regards,
Nicolaas

[Eli Cochran]

Nico,
Thanks. I think that this is a great idea.

I have to say that sometimes it is hard to tell what is a feature request and what is a design bug. I'll try to be good and use the new system, but occasionally there are issues which severely impact our users that I may still write up a JIRA*. Should I do both?

Thanks,
Eli

> _______________________________________________
> sakai-ui-dev mailing list
> sakai-...@collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ui-dev

. . . . . . . . . . . . . . . . . . .

Eli Cochran
project manager, CalCentral project
manager of user experience design
Educational Technology Services, U.C. Berkeley

"Do not solve the problem that’s asked of you. It’s almost always the wrong problem."
- Don Norman

[Steve Swinsburg]

Jira has worked well for the Sakai CLE over the years, there is a feature request issue type, priority and voting. You can create filters to find all sorts of issues.

I'll suggest sticking with Jira. Moving to something else risks fragmenting the two projects further.

Steve

Sent from my iPhone

> _______________________________________________
> sakai-dev mailing list
> saka...@collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-...@collab.sakaiproject.org with a subject of "unsubscribe"

[Bruce D'Arcus]

On Sat, Aug 27, 2011 at 6:03 PM, Steve Swinsburg
<steve.s...@gmail.com> wrote:

> Jira has worked well for the Sakai CLE over the years, there is a feature request issue type, priority and voting. You can create filters to find all sorts of issues.
>
> I'll suggest sticking with Jira. Moving to something else risks fragmenting the two projects further.

But Jira is not in the least bit user-friendly to the average user
(nor even to people like me with some development experience).

If you want to encourage more direct input from users (and I think you
should), you need something other than Jira.

Bruce

[John Norman]

Perhaps the right way to think about this is to use JIRA for issue tracking and try this new thing for developing ideas and turning them into trackable issues.

Just a thought from someone who's heart sinks every time he has to use JIRA. It really is a developer tool.

J

_______________________________________________
sakai-ux mailing list
saka...@collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-u...@collab.sakaiproject.org with a subject of "unsubscribe"

John Norman
Director - CARET
University of Cambridge
jo...@caret.cam.ac.uk
+44-1223-765367

[Bruce D'Arcus]

On Sun, Aug 28, 2011 at 2:51 PM, John Norman <jo...@caret.cam.ac.uk> wrote:

> Perhaps the right way to think about this is to use JIRA for issue tracking
> and try this new thing for developing ideas and turning them into trackable
> issues.

Exactly.

I realize there are some trade-offs here (it would take work to curate
this sort of separate idea tracker), but as a general rule the Sakai
world needs a much more substantial and direct, unfiltered, input from
users. This would likely have some direct impact on OAE in the form of
new ideas, etc. But it can also have important indirect impacts in
terms of enhancing the community of people that have some stake in the
project, who can be its advocates on campuses, etc.

OAE provides an opportunity to facilitate this in a variety of ways,
and I think Nico's idea here is one of those ways.

To again bring in the Google+ example, one thing I find interesting
there is the degree of engagement between Google engineers and PMs,
and their users. Equally cool is their integrated "send feedback"
features that allows one to send feedback, complete with all the
system info + a screenshot, to Google.

Perhaps this would be really ideal for OAE, if more difficult to
actually implement (because no ready-made code or service).

Bruce

[Bruce D'Arcus]

On Mon, Aug 29, 2011 at 12:21 PM, Kenneth Romeo <ke...@stanford.edu> wrote:

> So what happened to the teaching and learning group's role in all of this?
> ... One part of the way forward is more clearly defining the
> boundary between the pilots and the future of OAE, so that we can identify
> a process to negotiate where ideas should be addressed.  But the key is
> probably more active participation (for me, too), which means defining
> *how* interested parties can participate ... outside of ponying up cash or
> people, of course.

On this point, a thought:

A big argument for the OAE strategy has been that it's built on
principles of user-oriented design, and that it incorporates user
research and testing towards this end.

But I wonder if there aren't some missing opportunities here to better
bring the expertise of the T & L group, and of users, to bear.

I see, for example, two key pieces of functionality OAE will need to
tackle in the future: learning activities and assessment.

So what if each of those areas of functionality had a page on
Confluence with clear user stories and requirements, and maybe some
very sketchy mockups that articulate one or more possible broad
approaches. Ideally these should start from the student view; of their
dashboard page in fact.

You then solicit input from the T & L group, and run the mockups by
some user (in particular student) testing to get a better sense of
what makes best sense as broad strategy.

Then iterate from there.

It seems to me this is likely to ensure better outcomes, and to
exploit (and in turn further build up?) user and community resources.

Some of this is happening already, but it's not really clear how it
all fits together, and how, to Ken's point, one meaningfully
participates.

Backing up, I see the idea tracker as more likely to relate to details
in the context of the broader strategic directions that might be
developed by the above process.

Bruce