After thinking over the screens I posted earlier, I realized there were a few things I just wasn't thrilled about. So, I took another swag at it.
Summary
- What you'll find in these screens is that the broad structures have changed, but the detailed interactions (ex: adding content) have not
- The start screen with the 3 boxes has been replaced with more of a dashboard looking screen
- There are tabs now that allow the user to navigate between the dashboard, the build/edit mode, and the preview
- The portfolio list view is a lot cleaner now, IMO
- This approach also brings the design closer to the new Sakai 3.x direction
Enjoy!
| Zip archive of all screens (Week 2.1) |
Comments (4)
Aug 31
will trillich says:
1: three tabs: my portfolios, others' portfolios i have access to, and... a 'bot...1: three tabs: my portfolios, others' portfolios i have access to, and... a 'both' tab? hmm. i'm wondering what the 'both'/all tab would look like...
1.1: i do like the 'favorites' approach.
2: do we need the double-discouragement for the free-form portfolio? i'd think '(Advanced)' is enough of a warning, doesn't seem like it's warranted to say 'not recommended, abandon all hope, ye who enter here...' hey, i don't like free-form portfolios either, but we might as well let folks use them without going all agenda on them. i'd like to think that they'll have enough frustration with the free-form that they'll pressure their faculty to commit resources back to the community to make the tool better.
and yes, i definitely agree that there's absolutely no need to 'jargon' these up with template-this and template-that. that's what it is behind the scenes; out here, it's just how folks make portfolios.
3: if you were going to have an 'expires' field, it would go here, near the 'active/inactive' status field.
nice green-message guidance here. nice use of tabs. nice quick-start guide idea.
3a: ah, the build/edit menu... in some ways i prefer the previous rendition (screen 3 on your week 2.0 screens) which provides the end-user more context before delving into the process.
3b: no green-guidance once the portfolio has been started. nice!
4: okay, here's the bowels of the portfolio-creation process, where the end-users adds recipe ingredients. i'm glad to see you've got the three add/configure/share menu-options available as tabs on the left here. keeping them visible helps establish context so the user will understand what's going on a lot better than if they were all buried in a popup menu.
this particular template 'recipe' has five 'ingredients' for the user to fill out. some templates could have dozens of recipe-items, or just one, but this layout you've got here should scale well.
5: the 'configure settings' area now looks like it's addressing the outline-options-form step. here the sole form-field is 'presentation name'. the other item, 'display name', is a name to store this form under, in the user's resources area. when there's no outline-options-form at all, this section wouldn't be needed at all.
but, when it is needed, it'd be GREAT to bypass the display-name field. this very instance is the ONLY time the user will interact with it, in specifying options for this portfolio – so why not name it automatically behind the scenes, bury it in a portfolio-interaction subfolder and quit confusing the user with having to give the form a resource-name?
6: the sequence troubles me – shouldn't be a nice progression from none, thru some, to all? private, shared, then public.
these are all great strides toward a conscientiously-designed interface, which is awesome. not meaning to knock whoever put the current interface together, but it wasn't very user-centric. Nathan's approach is. go, dude!
Aug 31
Nathan Pearson says:
Great comments Will. You really studied these screens, and that's exactly what I...Great comments Will. You really studied these screens, and that's exactly what I need from community members.
I'll just respond to a few of the more salient questions:
Now I could have created another screen or screens for all those in addition to the three block screen, but instead, I opted to roll everything into one dashboard screen that hopefully emphasizes the three main tasks with the Quick Start Guide.
I'm not sure I was completely successful with that rendition, so I might still play with it to bring more focus to those tasks... but I have to estimate the cost/benefit by getting more user feedback on this latest design.
Private
Share
Public
The the following would happen:
Private
Share
.
.
.
.
.
.
.
.
.
.
Public
You see, once the user selects "Share" all the options push the "Public" choice down to the bottom of the page. It virtually disappears. To avoid the issue, I swapped their order. I figure the slight logical wrinkle outweighs the potential for user error.
Besides, most users wont catch on to the issue (I suspect), particularly since there is a symmetry with the Private | Public options being in close proximity.
Thanks again for the thoughtful comments!!
BTW, don't worry about giving me a big head. In my line of work, I usually hear negative feedback, so it balances me out
Which btw... I like hearing positive feedback (who doesn't), but honestly, the more negative/critical feedback I get, the better. So long as it isn't dismissive, I really like/need to have every detail challenged.
Sep 03
Sean Keesler says:
I realize that you are concentrating on the portfolio authoring process, but I'l...I realize that you are concentrating on the portfolio authoring process, but I'll mention this before I forget it.
The interaction between students or students and teachers would still require a bit of clicking to "discover" if anything new has happened. Can you incorporate something to make it obvious to a student/teacher that an interesting event has occurred ("there's a new comment on your portfolio OVER HERE", "a new portfolio you've never seen is OVER HERE", or "THIS SHARED PORTFOLIO has changed since you last viewed it"). I'm not sure a table of portfolio names really brings out that aspect...
Sep 03
Nathan Pearson says:
It's good that you documented this suggestion, but I suspect we'll not have time...It's good that you documented this suggestion, but I suspect we'll not have time to fit this into 2.6.