29 September 2009, 22:25

I have a number of concerns on the original proposal, some of which have been addressed in your update ... such as eliminating the construct of directly accessed views and complicated controls for access to them versus when they are shared in a site.  Also, the simplicity of WEB SITE (or view) with multiple pages is a simple and straightforward concept for the user UI.  I'm still concerned that we need to keep the simple and straightforward case as just that ... simple and straightforward.

The attached sketches are based on the LeaderTracker theme which rearranged the page components and mahara navaigation ... and to make an easy forward/back editing task progression bar.  Otherwise the code and mechanics on the pages are identical, but reskinned.
-------------------------------------------------------
SLIDE:  CreateSiteConcept-slide1.png
When you create a new site, by default there is only one page, it is titled "Home" and there is no navigation displayed if there is currently only one page.

** This keeps things simple and conceptually identical to the existing functionality without adding new concepts like sites versus pages.  To the user ... they simply create sites and we give them ability to create, share, or copy pages ... (which in the old days were views).  So access is always controlled for the site.  How you do this architecturally is totally up to ya'll ... whether you keep views and add an spanning site construct, or you keep the view and add a page construct.  Since all logic for sharing views is very complex, robust, and built ... I'd tend to simply rename "view" as site on the interface and architecturally create a page construct somehow so you don't have to change any of the other logic in the app.

Notice that users can simply start creating their content right away ... just like before ... nicely keeps SIMPLE simple, and COMPLEX possible.  All the paging complexity is only introduced if a user adds additional page(s).

-------------------------------------------------------
SLIDE:  CreateSiteConcept-slide2.png
Of course, this popup is only necessary if the user decides to add another page ... starting a new site from scratch has a blank page already.

The default is to add a blank page.  If I choose one of the other radio buttons, the popup form morphs to remove title and link fields and offer a FIND and CANCEL button ... see slide CreateSiteConcept-slide2-if you choose share.png for how it morphs.  This also keeps us from unnecessary querying to find the other pages when all they want to do is add a blank.

-------------------------------------------------------
SLIDE:  CreateSiteConcept-slide3.png
If I add a page, the system will default to TAB navigation ... automagically adding a tab that matches the link title entered on the popup.  Walla!  Easy.  If I change my mind the DELETE option will remove the page.  When deleting a page, if the result is only one page remaining, then the tabs automatically disappear.  A couple rules:
[1] The user CAN delete the home page, but the system will ask what the new default page is if there is more than one other (if there's only one left, it is the default and the tabs disappear anyway when I've deleted the 2nd to last tab).  Users can also manually adjust the default page using a popup associated with the link "change my web page navigation" at the bottom right (notice this link only appears if there is more than one page)
[2] Yes, the user can edit the link name and title of the Home Page.  They can even change the link title from HOME to whatever they want.
[3] The user cannot delete the last remaining page (there must always be a page) ... alternatively, you could let them do so but the system would respond by creating and displaying a blank home just like slide1.

The user clicks on the tabs to go edit that page.  So its easy to navigate while building because its the same way you navigate the site you build.  Future alternative naviagation can be menus, link panels, side tabs, your explorer, etc.  But the system must automatically create a navigation for the user.  We allow them to manually override and configure using the "change my navigation" link.

Although not necessary now, but it would be cool if the user can use drag and drop on the tabs to change the display order.  That might be tough since clicking on them is also a navigation event.

If the user has too many tabs, there is a scroll button on each side for previous/more (I can sketch if you don't know the control structure I'm talking about).

Note that on the real page, if the page title is blank the space should not be there (display: none) so there's not awkward space on the page if the user chooses to have no Page title.

-------------------------------------------------------
SLIDE:  CreateSiteConcept-edit page title popup.png
If you click delete, removes the page from the site.  If I click edit it gets a popup as one would expect.

-------------------------------------------------------
SLIDE:  CreateSiteConcept-slide2-if you choose share.png
As alluded to previously, if the user chooses copy or share, the title and link fields disappear and you get the find and select page option.  I've shown the share option in this slide since its a bit more complicated ... but the copy would be the same except no warning is necessary ... and the title and link fields would default to be the same as what you copied.  In the case of a copy ... obviously the user can use the edit feature to create a unique name and link for use in the website under construction.

Ok ... back to talking about the share case.  As shown in the warning ... the title, description, link title, and content are identical (pass by reference, so to speak) ... so any change will occur on all web sites sharing the page.  When I click find and select, I get the next popup.

-------------------------------------------------------
SLIDE:  CreateSiteConcept-slide2-selecting a share.png
Keep it simple ... user has to select A PAGE ... so we display a list of PAGES instead of a funky explorer tree that starts at the site level ... but add the information as to which web sites it is already in. We repeat the warning for users.  We don't care about hierarchy and navigation within the other site ... we keep it simple and manageable ... you can share or copy pages.  Each site can place the shared page anywhere in its own site navigation.

The copy popup would be identical to this except it would say copy and the warning wouldn't be there ;-)

---------------------------------------------------------
SLIDE:  CreateSiteConcept-reminder notice if page is shared.png
If the page is a shared page ... it is editable just like any other page!!  We simply add the "gentle" reminder as a warning at the top.  That might seem like overkill given the other alerts ... but don't forget that when I come back 2 hours or 2 years later, I might not remember that this particular page is a shared one.

Notice that there is an additional REMOVE option.  Remove will remove the shared page from the site.  If I choose delete, a warning box would appear indicating that deleting will delete it on ALL web sites.  That way delete is consistent in all editing situations in that it literally deletes the page.  It also eliminates the requirement for having a page list to manage.

This begs the question about what if I remove on the last website ... don't forget, the remove option only appears if the page is shared ... If I removed the page from all the other websites and I'm on the last site that had it ... then by definition the page is NOT shared ... remove would not be an option and only the delete option is there ... no orphaned pages that way ;-)  So it's important the logic looks at the page ID to see if it is shared on other sites at the time of editing ... NOT A FLAG THAT MARKS IT AS SHARED.
--------------------------------------------

I've not mocked it up, but the link "change site navigation" would allow users to (A) select between the type ... tab, menu, side tabs, explorer tree, etc.  This lets us add new ones over time as development resources permit.  Depending on the context, it might also allow users to alter the order and position of the tabs or hierarchy tree like Penny's sketch ... but again ... its an advanced option that is there waiting for the user who realizes that menu or tab won't do and they want an explorer tree.

----------------------------------------------------
SUMMARY:  I think this very workable and a straightforward approach from where the system is now.  It puts a little more work on us as developers, but the usability is so much more than introducing an new concept/construct to the user that requires them to understand what all these other pages and constructs are used for.  Existing users will simply interpret this as .... "oh, this is the same as I've always seen but now I can do multiple pages on my views"

30 September 2009, 1:15

Hi Ray & Nigel,

First up - agree with you completely Nigel about wanting to avoid confusion in the interface. When showing Mahara to potential users I tend to get widely varying responses on how good they think the usability is, so it doesn't surprise me to hear you mention similar. I am also very grateful to have got the support of Penny, you and now Ray to help thrash this one out.

I have, due to time pressures, been more focused on the end result than the process flows involved in creating multi-page views (my bad), so it is great to see some ideas bouncing around. Ray's mock ups look fine to me - driven by the process that I think most people I speak to would like to use anyway, logical, and the only little question I had in my head was about not being to directly access/edit pages. I was wondering whether there should be a 'My pages' list somewhere so that a user could edit one specific page directly, but I can see the potential for confusion and why we would want to drive users to edit pages only through a website view.

Ultimately I know two things:

1. Any of the suggestions that I've seen in the last few days are better than what the users have now, which is nothing, so I'm happy as long as there is progress in any direction; and
2. There are people far better than me who can design the right interface and process flows, so if the suggested method make the most sense (looks fine to me) then I'm all for it. 

30 September 2009, 11:18

My fear is the presentation of both "My Web Sites" and "My Web Pages" to the user ... particularly novices who will not find a sharp destinction between the two since, at least here in the US, the two terms are used synonymously in common everyday speech.  If they stop and think about it, it will make sense ... but I'd rather avoid the novice going to My Web Pages and not able to figure out how to get it published.

Second, I draw the analogy to your every day Word processors.  Your finder or Start Menu doesn't give you the option to create a page or document ... they simply start by creating a new document and pagination occurs naturally ... with some advanced features tossed in to control pagination, switching page orientation, etc .... but in the simplest case it occurs "naturally" and novice is simply successful. 

Microsoft Office actually had an advanced feature that they put in a number of years ago (Binder) for binding a number of documents together, as well as some features to allow linking and embedding other documents into a master document.   Getting any typical user except content managers to grasp these features and use them consistently and reliably was a massive training burden.

However, in our case ... in the web world ... people will not want to have rewrite the same web page over and over in different portfolios ... so I definitely see the need for shared pages as I think a sizeable minority or small majority of users are likely to find themselves wanting that at about their 3rd or 4th web site.

So I think the answer is not to have two major navigation points, but to allow a user to shortcut to a specific page.  This is very likely.  I think users will know which page they want to edit ... and will ask for it fairly soon so they don't have to start at the default page and then surf to edit it.  The list of web sites (views) is the natural candidate.  I confess I've not ever thought the up front list of artefacts and description necessary on that page ... so I've made the following mockup of a change on that page.

Since having done the mockup, I've had occasion to think twice that we should let the pages be links to the page (like the site title is) and then have edit and delete (and remove if shared) options.  We might consider only having an edit if it's too difficult to delete pages from this point.

Although other options can be investigated explored, I think what I've sketched is at least one potential solution that synthesizes the competing requirements.

30 September 2009, 19:35

Hi Ray - thanks very much for your thoughts! As resident HCI expert, you're adding a lot of value to this (and other) discussions, and I hope we can follow through and turn into great results 

I quite like this new layout for this page, though I'll offer one comment (though maybe it is more of a "thinking out loud"). When a View gets lots of pages, that listing will grow quite long. I suppose this is a side effect of the tabbed based navigation for View pages you have initially proposed. Maybe the lack of space for tabs would encourage people to keep the number of pages down, even despite controls to scroll through the tab bar, so it might not be such a problem initially. Though if we, in future, added some kind of hierarchial navigation there could easily be many pages. Maybe at this point, you only show the top level pages though.

Heh.. I guess it is just a thinking-out-loud 

I have some minor quibbles about the proposed layout, but I think they're better solved when the My Views/My Websites section gets some kind of organisational capabilities (e.g. potentially View folders). That is a mission for another day 

30 September 2009, 5:18

Hi Ray,

First, thank you very much for your feedback on this and the time you've put in, it's fantastic.

I have a few comments:

1. Don't forget that this must degrade to work without Javascript. Many of the comments about things morphing and happening dynamically must be able to be handled with javascript off, in a reasonable way as well.

2. I see you're differentiating between delete and remove for pages, which is one of my concerns.  However, I think there's an argument against being forced to delete pages if they're not in any other views - you might want to remove it from the current view, but put it in a view you haven't created yet.  In that case you almost need to have a way to manage pages outside of this website creation wizard...  what if you remove a page (rather than deleting it), because you want to put it in another view later, but then later you change your mind and don't want to do that.  You're forever stuck with it, unless you add it to a view and then get the option to delete it, which is also not good, usability wise.    Similarly, if you wanted to delete a page that was in 6 views, you would have to remember exactly which views it was in, so you could go to that view's edit page and delete it... which is also a bit weird to my way of thinking.

3. Ordering. I know you've talked about a popup to change between different types of navigation, and you also mentioned drag/drop for reordering tabs.   I don't think the drag/drop thing is doable simply because of funding at the moment, and again, we have to come up with a way that degrades nicely.  Given that,  I would be tempted to add little left/right controls on the tab titles themselves in this edit screen, and then the complex hierarchy/drag drop/whatever we want, can be added later.  How do you feel about this?

Thanks again for your input, it's greatly appreciated.

Cheers,

Penny

30 September 2009, 12:10

1.  JAVASCRIPT 

<begin soap box>

Aside from the techie in me thinking it's like wanting to have a car without glass because you're afraid the glass can shatter ... the usability of the car degrades without it at about 20 mph ;-)  But getting specific ... its a well documented problem that when you present fields and options that contextually are not relevant or incompatible ... user confusion and human error rates skyrocket.  Also, the more "noise" (amount of data, number of controls, etc) ... on a page without skillful techniques to differentiate them ... the time to cognition grows exponentially.  Also, the number of and amount of page transition (%of page changing, and number/frequency of change) is also a major problem that not only slows cognition, but causes disorientation and loss of context.  This is why carefully chosen popups, background dims, task progression controls, and dynamically presented controls are extremely useful tools in carefully designing user interaction.  Achieving this without javascript and flash is not impossible, but going into a fight with one arm, one leg, one eye, and one ear!

</soap box>

I understand you have clients that have strange javascript requirements.  In this case maybe we simply ask the question first (blank, copy, or share?) ... then lead them in the right path.  Asking for link title and name on a shared page is asking for trouble and confusion.

So we should not punish javascript users with an un-usable system.  In this case, if they don't have javascript ... I don't see how you can avoid page transitions (risking user losing context of their actions).  If it's modularized in its implementaton ... you should be able to ajax back and forth for the popup ... and use the same core modules for page(s).

2.  REMOVE

Actually what I've proposed is that remove only appears if the page is actually shared ... meaning it is used in more than one web site.  It's not a flag ... it's a detection whether the page currently has more than one parent web site using it.  This way remove can never appear if it is on "the last page having it."  Thus the orphaned page case should not really be possible.

So the user is not forced to delete shared pages ... but I don't think it's a stretch that you can't copy what's not there.  So a user wanting to move a page from one site to a new or separate site would be smart enough, I think, not to delete it.  Accidental clicks can happen ... but that's why we have a popup asking are you sure you want to delete.  In this use case, however, it can be simplified by offering a copy and paste operation (of pages) between web sites.  But I think that's a secondary priority but admittedly could be very wrong on that.  If we think people will "copy and paste" pages like people copy and paste elements of text in email and documents (which is quite possible, perhaps likely) ... then maybe it should be an early requirement to allow that interaction mode in addition to the mode in my mockup.

3.  ORDERING

I agree.

01 October 2009, 18:35

Taking in mind both Penny and Ray's thoughts on delete vs. remove, Penny and I had an IRC conversation about this issue (Penny with her Mahara Project hat on instead of her Client hat ). We came up with an alternative model that I believes addresses most of the concerns. I'm not going to say it's perfect, and it may have some issues of its own, but I think it's a reasonable compromise.

Rather than having two "destructive" type buttons on shared pages, an alternative idea might be to have just one button for any type of page: "Delete". For non-shared pages it'll behave just as Ray suggests - an Are You Sure? popup, followed by  removing the page forever. For shared pages, we borrow a concept from calendars and repeating events. It asks "Do you want to delete this page only, delete this page in every site it exists (perhaps showing a list of sites), or cancel?".

This removes the potential confusion between "removing" vs. "deleting", and keeps the property that there are never any orphan pages. It's also (correct me if I'm wrong here) a model that users who have used a calendar will be quite familiar with.

On its own, this doesn't address the issue of moving pages from site to site. But a logical extension might be a new page where you can manage all of your sites+pages from a "top down" or "explorer" interface. I have mocked this up here: http://mahara.org/view/view.php?id=5902

On this page, you would see a tree structure of your sites and the pages within them. Beside each page could be edit and delete links. If you clicked edit, you'd be taken to the site editor, with the current page being the one you chose. If you clicked delete, you would get a similar popup as if you were actually within the site editor and clicked delete (e.g. Delete this | Delete all | Cancel). You could use drag and drop to move pages between sites, and even use this mechanism for copying. e.g. dropping a page could trigger a "move here/copy here/cancel" dialog.

I'm not sure what name this page would have, but for argument's sake, let's call it Web Site Manager (perhaps more portfolio minded people could call it My Portfolios, or Portfolio Manager). This page exists AS WELL AS the current My Web Pages/My Views page. Perhaps as a subtab of, or linked from, this page. If we rework the navigation to be like how Ray's main navigation is, then this page is another entry under the Sharing menu.

I just realise that I forgot to add a link to allow a user to create a NEW page from this manager, but you can assume it's there 

I think this is a good solution, because then there's never really any confusion when it comes to moving vs. deleting pages, and deleting the last page. If people actually want to move pages, they'll be far more likely to head to this screen, where they can see both sites at once. Potentially, moving/copying could be implemented as a "push" operation within a site (e.g. right click on a tab -> "Move To" -> pick a site), but that wouldn't be strictly necessary if we had this page.

Penny and I talked about this a bit, and decided that while the moving problem is an annoyance, it's not necessarily a blocker. Which means that we could implement Ray's proposal with the delete change in one go, and then add the web page manager screen later (potentially with different funding).

I realise this might not be a perfect solution from all points of view - maybe it would be more sensible to include move/copy controls within the proposed designs up front. But given how funding works, I think we're going to have to make compromises that people can live with.. unless someone wishes to assist with funding the "perfect" solution?

I wish it wasn't that way really.. if I had my way I'd say that the core would contribute in a heartbeat. But that won't fly with the beancounters  

02 October 2009, 15:59

Hi Nigel and Penny,

"It asks "Do you want to delete this page only, delete this page in every site it exists (perhaps showing a list of sites), or cancel?"."

I like that idea more than having to distinguish between "delete" and "remove". Some languages may not have such a clear distinction of these terms anyway.

This concept is pretty straight forward in calendar software and using it here in Mahara would be good I think.

Have a nice weekend

Kristina

04 October 2009, 23:44

I wholeheartedly agree with your proposed simplification of one button that contextually asks whether to remove it from just the site or all sites a page is shared within.

However, I don't agree with your proposed "web page manager" as another main navigation point.  If you pause to think about it, it is really just "My Web Sites" and "My Web Pages" done over with a different label.

If you note from my previous comment that I proposed that you refactor the "My Web Sites" (currently My Views ... with their equivalents for group views and institution views) so that the pages are simply listed right within the list of views.  If you think about it ... with multiple pages the artefact list will be untenable anyway ;-)  There simply is no need for a separate page duplicating the key information (a list of views) and the pages ... whereas the other has artefacts and links for editing.  It's much simpler to have it all on page (you can make expand collapse to view pages if you want to temporarily hide the pages under the view "Web Site" title ... but I think that's overkill for a first go round).

If you take your sketch Nigel ... and add edit Site title, edit site content and layout, and edit access to site ... you've essentially duplicated my proposed remake ;-)  So replace the old My Views (My Web Sites) with the new My Web Sites (using your web page manager sketch but add the 3 additional edit links).

I would take care to build this multi-use ... in the sense that in my sketch of the edit page content and layout ... there is a link to edit the site navigation.   That should simply open up the same page as your sketch, but with only the current site available (rather than all of them).  Personally, I'd prefer they share a json retrieval rather than the same REST page .... so that in the edit site navigation link we could use an in-page popup to do the work instead of a page transition ;-)

The only problem with this is if we implement a menu based navigation mechanism or hierarchy tree ... then we'll need to have specialized icons for these so the user will be able to tell if they are looking at the menu or the page ... but that should be doable.  I'd use a site icon (we use a portfolio-ish icon) and then a page icon for the pages ... rather than the page and twisties you've implied (but probably is due to your sketch utility).

05 October 2009, 19:08

Firstly - agree about the artefact listing. It used to make more sense, especially under the "old" View editor (pre 0.9, you would have clawed your eyes out had you seen it ). But no so much any more. So your proposed layout for My Views/Sites is fine with me in that regard.

If my mockup was to replace yours however, I feel like we'd end up missing some important information. For example, the list of who can access the View. The list of artefacts might be a little unimportant, but the list of who can access the View is definitely of interest. And I can't think of a nice place that it would fit in an "explorer" type page layout. Likewise, the extra links you propose could fit in, but only all together next to/under each site's title, which could cause issues. For example, if the links are side-by-side, they probably present in a confused jumble, while if they're on their own line each (similar to your mockup), they're easier to comprehend, but will take up quite a bit more vertical space.

On top of that, going to an explorer type model means you have to load every View, plus all their pages, on one page. Some people have more than 40, and there's no reason why someone might have many more. So vertical space is really at a premium.

Perhaps a summary of the above is that combining the two pages might make the one page quite busy  

At this point, I begin to wonder: what if it was done in a similar way to how the iPhone manages "display" vs. "edit"? E.g., have an "edit" button that literally morphs the page into having edit/delete controls for the pages and ditches the links/access list. Maybe it also has links to edit/delete the sites too, alongside their name. In this mode, the listing is compact, and drag/drop for moving pages can occur. If the user hits the "Done" button (which replaces the "Edit" button), the display morphs back to the traditional listing, with buttons for access, access list etc.

I guess in some ways, this is still having two screens. Though they'd be under one tab . Even if we did a non-javascript version, it could be displayed under the same tab.

Am definitely open to alternatives, and/or thoughts on this suggestion.