E-mailAttendees
Michael Korcuska
Nathan Pearson
Nico Matthijis
John Norman
Oliver Heyer
Allison Bloodworth
Eli Cochran
Daphne Ogle
Jess Mitchell
Colin Clark
Kirk Alexander
Clay Fenalson
John Leasia
Lance Speelmon
Megan May
Mathieu Plourde
Notes
- michael: we just kept the functionality building a site from scratch * no templates, copying a site
- michael thinks preferences, join and edit sites could be chopped off
- michael: there is a risk this work won't be done by code freeze
- michael: 2.7 - some more features could be there * michael says this will make oliver cringe
- still must QA old mechanism,
- ?? doesn't think they could use it; nothing deals with course management data, needs to choose sections which will be assigned in a site
- leasia: Dependencies in the UI on settings in sakai.properties (edit project site title and not course site title), they also use portfolio and grad tools sites, other institutions have also implemented other site types; selecting multiple sections for a given course site, looks like additional fields or APIs it seems will be needed; this might be sufficient for new institutions it might be enough, but not for existing institutions
- norman: right way to look at it is it's a replacement and there are gaps that need filling in the bug fixing cycle or somewhere else; the idea that it's like a skin is probably problematic; a functionality gap may be an oversight; is there an interest in contributing a resource to fill those gaps; if there isn't it probably won't be done for 2.6
- ??: thought site setup and worksite setup would be done for 3.0, we are interested in working on it if it's a replacement, not something that is a subset of
- kirk: hard to figure out the gaps until we start working on it
- michael: want to get started to learn what the gaps are (course management api handling is obviously a gap) * is it worth getting started even if it won't be done by oct (code freeze)
- clay: view skewed more towards 3.0 work; wants people using 2.6 to settle the question of what will go into the product
- oliver: the same position; we are looking towards 3.0
- ??: can we do kernel work for 3.0 and this work serially; probably not because they need to inform each other
- megan: what will the technical changes be? can we go over at a high level
- michael: hard to go over at a high level
- norman: nico & ian's time, technology we used in mycamtools, repackaging of data, create screens with javascript
- oliver: course management could potentially change; possibility of changing that service to accomodate cambridge's use case (triposts)
- michael: what if create a site went away and went to the existing create a site, then all you'd have is the dashboard assembly and the rearrangement of the preferences
- ??: will local customizations require rework to accomodate layouts and stuff (e.g. login)
- eli: html, css; we have some incredibly skinnable HTML and I want to make sure that gets built the same way
- ??: nico may need to work with some of us to understand our customizations
- eli: as people build new tools they can use the css that's there, and that does require some work and thought; ideally getting someone like gonzalo or me who have done skinning systems and breaking them down into widgets thinking about it semantically and documenting styles, hierarchical styles and semantic markup (eli can't commit to this work, that's up to oliver)
- nathan: some folks are looking for this to get started before they get involved; what's a good process for getting people involved? an active prototype is ideal, but that's not design-friendly; not a good process going forward; is anything we are doing going to be part of the product?
- ???: nico & ian need to get some of these ideas into their initial development
- norman: they won't deploy 2.6 as 2.6, are trying to get into the position to deploy 3.0; worrying to think they'd work on this and then folks will come along and say "this isn't good for us because it doesn't do x", i'd refocus them on 3.0 if I didn't think people would use it, that might include some of the same screens but they might be different
- lance: I'd like to figure out what can be done in the next 30 days with the resources we have and if we make it into 2.6, great. we could take on the create site functionality and try to sprint through that. (indiana) we'd deploy that in the spring, may, june. i think that given the work that's laid out we can't do everything, we just have to get started. it seems like a 30 day sprint could inform us about what could go into 2.6 depending on how mature it is. i'm looking at create site as it's speced out in the screen mockups.
- michael: even though it doesn't contain the section info stuff?
- lance: it looks like something that could be done within 30 days;
- michael: you're looking at scope and available resources rather than functionality?
- clay: trying this as a contrib product seems to be the only workable way forward
- michael: fine with me; sounds like cambridge and indiana would be willing to get started on this even if it doesn't go into 2.6
- clay: we are willing to commit resources, we have local and k2 commitments too; it would be good to have a project team to work with since we can't pull off a chunk ourselves; it's not something we could devote ourselves to putting in for 2.6, but are certainly willing to get the ball rolling for may-june
- nathan: if we do this we should put ourselves in the right mindset, aggressive, should be a foundational part of the product
- lance: next set of designs may interest IU more, it's not just a 30 day sprint, we have to get the ball rolling
- michael: a substantial piece of this is the framework for 3.0; should be usable for 3.0 but even if not we'll learn a lot by having something to put in front of users and QA even if we have to throw out the screens and redesign them from the ground up
- nathan: the screens are only going to get more complex; these are the simple ones
- norman: seems to make sense to cut the knot to 2.6, may want to use the 2 series code to support our prototyping; in any early version of 3 we'll need to accomodate legacy code and functionality because can't do a full migration in a year; screens were constrained in their design somewhat by sitting on top of the current sakai way of doing things; i'd like to suggest based on this conversation that we explicitly agree that we won't oblige ourselves to implement; sounds like michigan says it would be good to do a big changeover without having changes creep in; a replacement rather than a process
- michigan: makes sense for us to think about; we wouldn't deploy interim changes that won't do everything you need
- ??: should we accomodate local concepts in skinning
- norman: i've always assumed we would allow skinning; if eli is saying that hasn't been taken into account, where can we get some resources for that; john thinks the difficulty of skinning sakai is one of the main problems; someone they had skin sakai it took a week; he would have thought it should take a day; this isn't as high a priority as it should be internationalizable and accessible. The reason it's the way it is is because of how it came about; nathan used someone who could rapidly turn his images into implementable html; rapid prototyping; accessibility: preferable type functionality & keyboard navigation;
- jess: we will have transformable in the fall; september; we're remaining flexible to see what work can be done in the sakai area; we are looking to work with someone who has a well-defined scope; john's christmas timeline is resonable for a refreshed version of the transformable tools (colin agrees timeline is good); our roadmap is remaining flexible in the fall so we can settle on the fluid framework and API; implementation is going to happen in the fall; we are working with uportal and want to work with sakai; components fit into a context and we're well aware of this; we're flexible to work a little more broadly than just the component if it's well-scoped;
- colin: preferable and skinning are tied together; if we can do preferable well, we need semantic html;
- michael: is that sort of html expertise could be provided by fluid involvement?
- jess: yes, if it's well scoped, managed and there is a group to work with--that's the harder question
- kirk: figuring out what to do next; need fluid input into process; we had talked about getting nathan involved in the gradebook work; how our contribution aligns with this I don't know; i don't want to draw a resource from this but I want the same kind of input; we're just about ready to get back to nathan on his note to us
- sounds like john and lance are willing to provide resources, but other than that I'm not sure we have a team around this; hard to talk about a timeline until we have a team;
- john/mich: we are ready to work on a revamped site info
- michael: we are looking more for javascript skills for this project than the java services
- norman: nico advertised for some ux help in a discussion forum; ux trained people were in indiana and michigan; i'm guessing that there isn't scope for adding to your team but just thought I'd check;
- lance: can you give me pointers to those folks?
- michael: I'm hearing a desire for everyone to get started on this and I understand the k2 commitments are blooming as well, but a kernel without the interface isn't going to give us the value, looking for clay, john, kirk should think about your interest in 3.0 and whether the interface work would be helped by getting started on this work right away
- norman: way nathan is framing the site with the tabs down the right-hand side; where they are i assume you could customize; all of this supports the legacy tools being surfaced in that environment; these are user interactions we need whatever is underneath; only distinction between 3 and 2 are what assumptions we make about the back end; if there isn't a huge interest in putting this into 2.6 then it just relaxes the constraints on what we have to do
- kirk: would be an interesting discussion to have around something like the gradebook (technical)
- norman: key thing from my perspective is the experience we are trying to create should be limited by what 2.x can support, if no we are working on 3, otherwise we are working on a hybrid; if 3 is implemented in gwt that's great I don't care; just want to be able to deliver the user experience and have a flexible solution
- michael: aha, kirk is implementing gradebook in gwt, that's why he asked that question
- lance: john if we are willing to work on this iteratively, is this enough or does this still keep you in a holding pattern?
- norman: i think this requires patience & tolerance as we work through it because we haven't overturned all the rocks yet, but if we don't start, we won't finish.
- lance: we will contact nico offline and start with small iterations
- michael: please keep nathan in that loop as well as we begin moving forward
- lance: do we need a working group for ux improvement?
- nathan: maybe we need to start another meeting as it gets a little more tactical
- michael: sounds like we have cambridge and indiana to start the implementation of a few of these screens; if anyone else is willing send me an email so we have an idea of what resources we have to work with; I'd like to give jess what she's looking (scope and timeline) for so we can take advantage of fluid help as well
- ??: it might be helpful as you go through this process with indiana, it might be helpful to figure out how the sdata approach can be generalized;
- michael: someone has to write the javascript to create the html; we need to be careful about how it's constructed; but a lot of it will be wiring things together, yes; we can probably leverage this quite a bit in the future, but will be hard to figure out what it means until they start working on it;
??: might be easier to get people involved if they see how straightforward it is to do
michael: getting a lot done without massive investments; if that's the implications that's definitely true