[DG: User Experience] Feature requests for Sakai OAE

classic Classic list List threaded Threaded
9 messages Options
Nicolaas Matthijs Nicolaas Matthijs
Reply | Threaded
Open this post in threaded view
|

[DG: User Experience] Feature requests for Sakai OAE

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

_______________________________________________
sakai-ux mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Eli Cochran-2 Eli Cochran-2
Reply | Threaded
Open this post in threaded view
|

Re: [DG: User Experience] Feature requests for Sakai OAE

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

On Aug 27, 2011, at 10:17 AM, N. Matthijs wrote:

> 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
>
> _______________________________________________
> sakai-ui-dev mailing list
> [hidden email]
> 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




_______________________________________________
sakai-ux mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Steve Swinsburg-3 Steve Swinsburg-3
Reply | Threaded
Open this post in threaded view
|

Re: [DG: User Experience] [Building Sakai] Feature requests for Sakai OAE

In reply to this post by Nicolaas Matthijs
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

On 28/08/2011, at 3:17, "N. Matthijs" <[hidden email]> wrote:

> 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
>
> _______________________________________________
> sakai-dev mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

_______________________________________________
sakai-ux mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Bruce D'Arcus-3 Bruce D'Arcus-3
Reply | Threaded
Open this post in threaded view
|

Re: [DG: User Experience] [Building Sakai] Feature requests for Sakai OAE

On Sat, Aug 27, 2011 at 6:03 PM, Steve Swinsburg
<[hidden email]> 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
_______________________________________________
sakai-ux mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Charles Hedrick Charles Hedrick
Reply | Threaded
Open this post in threaded view
|

Re: [DG: User Experience] [Building Sakai] Feature requests for Sakai OAE

In reply to this post by Steve Swinsburg-3
Jira is a reasonable way to document individual requests. In my opinion it has two limitations:

* Someone who knows it has to make entries. I don't think faculty would likely be doing this anyway. Most likely staff would help them formulate and classify the request.
* Someone needs to look over the individual requests and put them together into something more coherent, organizing them, and prioritizing them.

I think these two things would be needed whether you use Jira or something else.


On Aug 27, 2011, at 6:03:58 PM, Steve Swinsburg 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.
>
> Steve
>
> Sent from my iPhone
>
> On 28/08/2011, at 3:17, "N. Matthijs" <[hidden email]> wrote:
>
>> 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
>>
>> _______________________________________________
>> sakai-dev mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-dev mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

_______________________________________________
sakai-ux mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

smime.p7s (5K) Download Attachment
John Norman John Norman
Reply | Threaded
Open this post in threaded view
|

Re: [DG: User Experience] [Building Sakai] Feature requests for Sakai OAE

In reply to this post by Steve Swinsburg-3
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

On 27 Aug 2011, at 23:03, Steve Swinsburg 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.

Steve

Sent from my iPhone

On 28/08/2011, at 3:17, "N. Matthijs" <[hidden email]> wrote:

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

_______________________________________________
sakai-dev mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

_______________________________________________
sakai-ux mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

John Norman
Director - CARET
University of Cambridge
[hidden email]
+44-1223-765367


_______________________________________________
sakai-ux mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Bruce D'Arcus-3 Bruce D'Arcus-3
Reply | Threaded
Open this post in threaded view
|

Re: [DG: User Experience] [Building Sakai] Feature requests for Sakai OAE

On Sun, Aug 28, 2011 at 2:51 PM, John Norman <[hidden email]> 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

> Just a thought from someone who's heart sinks every time he has to use JIRA.
> It really is a developer tool.
> J
> On 27 Aug 2011, at 23:03, Steve Swinsburg 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.
>
> Steve
>
> Sent from my iPhone
>
> On 28/08/2011, at 3:17, "N. Matthijs" <[hidden email]>
> wrote:
>
> 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
>
> _______________________________________________
>
> sakai-dev mailing list
>
> [hidden email]
>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to [hidden email]
> with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-ux mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to [hidden email]
> with a subject of "unsubscribe"
>
> John Norman
> Director - CARET
> University of Cambridge
> [hidden email]
> +44-1223-765367
>
>
> _______________________________________________
> sakai-ui-dev mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ui-dev
>
>
_______________________________________________
sakai-ux mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Kenneth Romeo Kenneth Romeo
Reply | Threaded
Open this post in threaded view
|

Re: [DG: User Experience] [Building Sakai] Feature requests for Sakai OAE

In reply to this post by Charles Hedrick
If I remember correctly, Clay's talk at Sakai2010 in Denver was about
precisely this issue:  in contrast to other open source projects, like
Apache, the developers are not the users.  He noted the importance of
identifying people and methods to negotiate the gap and pointed out how
crucial it was to the future of Sakai.
So what happened to the teaching and learning group's role in all of this?
>From my limited experience, that seemed to be the group of people who were
best situated to negotiate the transition from an idea to a jira.  I was
also under the impression that the URG was doing a similar thing, but for
OAE.  But maybe this assumption is not correct:  is the URG only about the
current pilots of OAE?  I just joined the URG list and it seems that there
are some very important topics being discussed.  It was very encouraging
that the members of that list are working hard to engage with tough
choices.  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.  
Ken

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Hedrick
Charles
Sent: Saturday, August 27, 2011 6:03 PM
To: Steve Swinsburg
Cc: [hidden email]; [hidden email];
[hidden email]; [hidden email];
[hidden email]
Subject: Re: [DG: User Experience] [Building Sakai] Feature requests for
Sakai OAE

Jira is a reasonable way to document individual requests. In my opinion it
has two limitations:

* Someone who knows it has to make entries. I don't think faculty would
likely be doing this anyway. Most likely staff would help them formulate
and classify the request.
* Someone needs to look over the individual requests and put them together
into something more coherent, organizing them, and prioritizing them.

I think these two things would be needed whether you use Jira or something
else.


On Aug 27, 2011, at 6:03:58 PM, Steve Swinsburg 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.
>
> Steve
>
> Sent from my iPhone
>
> On 28/08/2011, at 3:17, "N. Matthijs"
<[hidden email]> wrote:

>
>> 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
>>
>> _______________________________________________
>> sakai-dev mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
[hidden email] with a subject of
"unsubscribe"
>
> _______________________________________________
> sakai-dev mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
[hidden email] with a subject of
"unsubscribe"

_______________________________________________
sakai-ux mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Bruce D'Arcus-3 Bruce D'Arcus-3
Reply | Threaded
Open this post in threaded view
|

Re: [DG: User Experience] [Building Sakai] Feature requests for Sakai OAE

On Mon, Aug 29, 2011 at 12:21 PM, Kenneth Romeo <[hidden email]> 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
_______________________________________________
sakai-ux mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"