28 September 2009, 14:30

Hi all,

I'm currently in the spec writing process for three new features for core:

Multi-page views:  http://wiki.mahara.org/Developer_Area/Specifications_in_Development/Multipage_Views

Site/Institutional Tag Definitions: http://wiki.mahara.org/Developer_Area/Specifications_in_Development/Site_and_Institutional_defined_tags

Adding attachments (and inline images) to the textbox block: http://wiki.mahara.org/Developer_Area/Specifications_in_Development/Text_box_block_attachments_and_inline_images

These are targetted at 1.3.

I hope some of you will give me feedback! Please reply here and I'll incorporate your comments into the specification.

Cheers

Penny

28 September 2009, 18:43

Some questions after having read those specs:

Multipage Views 

• Any reason for denying profile views in sites?
• All the "very similar to Views" stuff makes me nervous.. I hope it will work in practice, rather than confusing people about what they're giving access to. Definitely want to see mockups of this 
• The view access screen might be changing quite a bit after 1.2, so don't count on it's layout remaining (referring to putting a banner at the top)
• Semantically, there is a "home page view" right? You haven't mentioned this, but presumably for your My Sites block, we have to link to one of the views to get going?
• I'm still unsure about the best way to do the navigation.. other ideas include a pull-out from the left/right side, or maybe integrating with the sidebar? Maybe they need mocking up.
• Probably not worth worrying about "site copying", as you say.
• It's not just LEAP2A export and import you need to worry about,  there's also the HTML export. That will add time to any estimate you do.

Site and Institution Tags 

Text Box (My Notes)

 

29 September 2009, 1:04

Hi Nigel, thanks for replying, I'll answer each of your points in turn.

Multipage Views

* Profile views - there's no reason why they coudn't be included, I just don't think it makes sense.  I suspect users don't really think of their profile page as something that's part of their portfolio.  I'm up to being convinced I'm wrong though.

* Mockups.  There were two mockups actually, can you be specific about what exactly else you would like to see mockups of ?

* Can you elaborate on how it's going to change so I can work that in to my idea of what the differences are between views and sites, it may change the way I see things.

* Yes, that's the "default" page I mention (and what the star is for in the mockup), although it's not made explicit on that it will be forced, whiuch I think is important.

*  Navigation Yeah I'm not really sure either. I don't really like the pull out idea, but I agree these could be mocked up. What did you think about giving the user the option to pick about what sort of navigation they want?

*  Fair point, but it's much less complicated than LEAP2A.

 Site and Institutional Tagging

* Well, the options are most restrictive wins, or least restrictive wins :) I'm a bit agnostic about it actually.

 * We're allowed to cross post?!  :) 

 Text Box / My notes

 Yeah, the "save in My Notes" thing is good.  I think if it should save in the background anyway and just make them hidden if they don't check it (and I think it should be checked by default too, probably). The idea of having these be a mix of both artefacts and non artefacts worries me (and of course they can't have attachments if they don't save them)

 

29 September 2009, 3:54

I am using web page functionality in Mahara a lot already so the concept does appeal to me as long as it does not become to restrictive or complicated in structure. At the moment I use a blog for navigating between views. As I have a lot of views, the thing I am really keen to get is 'View folders'. Would this be another layer of organisation or part of a web page structure?

On the issue of profiles, I think they are worth considering. Having just trawled through our site looking for 'best practice' examples I realised that most people are using profiles badly (or rather they have minimal information). Perhaps I am just curious but I think profiles could/should be important particularly for graduates.
We currently have 1,400 users (on Foliospaces) and many still struggle (for a while) with useability but that is also the price of the great flexibility Mahara offers over other ePortfolio systems.

Regards, Ian

29 September 2009, 5:28

Hi Ian,

Is this just an organisational thing for making it easier to navigate through one's views?  That shouldn't be hard at all but is an orthogonal project to the one being discussed at the moment (feel free to file a feature request though! :) )

I've updated the specification today and under the new spec it makes much more sense for profile views.  They just become multipage.

29 September 2009, 3:28

Nigel/Penny,

A few more bits of food for thought on this one, again I'll tackle them one by one.

Multipage views

Understand your desire to not make this confusing Nigel, but this is the biggest issue I face whenever I talk Mahara to a potential client. I think the mockups that Penny has done are good, maybe its a terminology thing to make sure that a view is clearly identified as something that sits within a site (maybe pages inside of sites instead?).

I can also see how there are workflow questions around the order you should be developing your work, i.e. create site -> add views/pages ->  add artefacts. Might take more effort to set up, but is still something that would be awesome to have.

Two questions:

1. How would the UI manage large numbers of views that a user might set up? Wondering if there is any thought that needs to be given to that.
2. Would access still be grantable at a view/page level AND a site level?

 Institutional tags

Comment on Nigel's query about this being a valid requirement - I can give a concrete example as follows.

A uni wants their students to gather evidence against a set of organisation-wide competencies. The institution sets up the tags for this and students can tag their artefacts accordingly. They can then be allocated a default site (i.e. as defined above - a collection of pages with a navigation structure) which has one page per attribute (for example), and then be able to, within a page, search for artefacts that have the appropriate tag, and link to them within the view.

That last bit - being able to search for content as you are adding it based on the tags it has against it - is actually an extension that came up when I was thinking about this seems like a logical thing to add to this functionality.

The result of this would be a way that students could easily populate a report on their achievements towards the graduate attributes, searching on the relevant tags and populating their template with relevant content (even though this would need to be done block-by-block I assume in the page/view).

Adding attachments to the text block

I think this is on the right track, but it might need a little more extension (maybe). The model of being able to manage the text block as an artefact ('note') is great for usability, and being able to use the functionality currently available in the blog entry screen where an image can be attached to a post and then embedded is a good starting point, but it raises two more questions for me:

Why is the user forced to attach an image first, and separately, before embedding it? I understand that it needs to be added to the post so that it can be exposed, but why can't this be done in one step - i.e. click the image button, and then allow users to select an image from their repository, or upload one and link it on the fly? Understand the logic behind it, but the workflow could use a little polish IMHO.

Why is this just limited to images, i.e. why can't I browse for a file in my repository when I am editing a post (or to take it to the next step when editing a 'note') when I click the hyperlink button, and when I select it then it automatically attaches it to the blog post as well as creating a hyperlink to it? This is linking to it rather than embedding it in the post, but this to me would be a great way of giving more flexibility to users in how they display their content, while using functionality that looks like it is already basically there in the blog post. I've mocked up a quick screenshot of how I think it could look - open to suggestions.

29 September 2009, 5:36

Hi Mark!

I think your first point about large numbers of views is the same as Ian's about view folders.  This isn't covered by the current specification, but could of course be added.

My original spec had access granted per view and per site (with site overruling), but the reworked version just has views with pages, and only views have access. I think this is much simpler.

I take your point about images, this could be included in the spec as well.

Artefacts, other content, are a bit harder, first because attachments at the moment is limited to "files", and second because it's an implicit granting of access. We can get around that by telling the user that the artefact they're linking to will be granted access as part of the view.

However, I can see the next point will be linking to other views... what do you do about access then?

29 September 2009, 7:03

Hi Penny,

Will check out the updated spec for the multipage views - I'll take the guidance of you and the Dev team on how best to do it, as long as the main features discussed are in there then that should be fine.

I wonder if it is fair to just limit the attachments to files and images - maybe I was getting a bit gung-ho in suggesting a linkage to all artefacts was a good idea. I can see the risk of getting lost in the k-hole - artefacts having artefacts as attachments, which could also have artefacts as attachments... I think for the purposes I've been talking about linking to files only would make sense - I'll update the screenshot to reflect that.

What do you think?

29 September 2009, 20:55

Hi Mark,

Multipage views

My desire is very strongly not to make this confusing . Mahara started from quite a poor background usability-wise, and through a lot of hard work and thought we got to where we are now - a state which people still regularly give us mixed feedback about.

From experience, if you're looking at something on the drawing board and thinking "this might be confusing" or "hm, this might cause a strange workflow", then you need to stop and think hard - because it'll cost less to come up with a better plan now than later. You yourself can see potential workflow issues, so I think it's worth spending a little more time to think things over 

Starting from the beginning: Lots of people want  what can be referred to as "multipage views" -  we've had feature requests about this from ages back (e.g. this one), and there's people prepared to pay for it now. But you have to ask whether what they want is "the ability to group views into websites", or whether what they really want is "a way to make more, related pages about this thing I'm making a presentation about". The key difference is, that one of them describes a mechanism, while the other describes a task. People rarely actually want mechanisms, they actually want to do tasks. If we know what that task is, then we have a better shot at giving them something they actually want.

Multipage Views as a mechanism does solve this problem, but it's not the only mechanism that would work. So I got Ray Merrill to have a look at the problem, and he came up with quite a neat solution, that intuitively feels much more usable. I've asked him to post it here, if he doesn't soon then I might post it myself.

I think Penny covered your first question - we need to think about what is currently the My Views page a bit. For the second one, according to the way Ray's idea goes, there only needs to be permissions at one level.

Institutional Tags

That sounds like a decent usecase. Given that the site can make a set of tags, and that institutions can make their own sets, it seems to me like there's already going to be the concept of multiple "tag vocabularies", if you know what I mean. E.g. the site has its own vocab (e.g. learning, reflection, playtime), while an institution has another (e.g. football, rugby, cricket). Which is why I asked Penny whether supporting multiple vocabs at the site/institution level might be useful as well, in order to broaden the use of the feature. But if nobody is that interested, then I guess it doesn't have to happen.

One thing that occurs to me while writing that is that I guess the site and institutions could create tags with the same names.. I guess this isn't a problem according to how Penny's described the implementation of the feature, though something worth keeping in mind.

Another thing that occurs to me is that a site level "ponies" tag could mean something different from an institution level "ponies" tag. Again, probably not that important, but it could happen. 

Adding attachments

I think you're dead right about the attach-before-embed thing, and we should improve that workflow. That is, in fact, one area where a while ago we received an extremely negative piece of feedback from someone.

The UI could work like you suggest, or maybe attaching an image would be a separate tab on that little popup (maybe even the default tab). Or maybe something else - would be worth someone mocking up 

29 September 2009, 5:22

Hi all,

I've come up with an alternative approach for the multipage views here: http://wiki.mahara.org/Developer_Area/Specifications_in_Development/Multipage_Views_Take_2 which I think is a big improvement when it comes to usability.  Please read that as well as the first one before commenting further.