[sakai2-tcc] Improve the welcome page experience

Matthew Jones matthew at longsight.com
Mon Apr 30 17:47:48 PDT 2012


Maybe I wasn't clear either I do think it needs improvement. ;)

1) The .html files that these QA's use are all in
https://source.sakaiproject.org/contrib/qa/trunk/

These "ARE" the scripts that most of the "legacy" QA servers should be
referring to for this welcome content and it would be awesome if someone
fixed them up.

Like if you look at QA3: http://qa3-us.sakaiproject.org:8086/portal

It's referencing
https://source.sakaiproject.org/contrib/qa/trunk/qa_server_info.html.qa3-us

Seth set this up years ago and either the "server.info.url" for the QA
servers is directly pointing to this, or it's downloading this document as
part of some ancient deployment script and referencing it.

These haven't been updated in years and I completely agree that they could
use some touch-ups, I was just saying that the specific QA admins don't
touch this info, but so many QA servers are *new* and are completely
outdated or un-managed.

2) I also don't know the history of where these servers have the "secret"
password that starts with an "s" for the admin user. Maybe there's some
reason to keep off generic passer-by from messing up the QA instance
(deleting important sites requiring database restorations/etc). That
decision was made long before me. Even on the Moodle QA site, the admin
role password isn't provided. Only on the demo site it is provided,
probably because the demo is wiped very often. Moodle has a full test
school.

3)  I think we'd need to make a distinction between QA and demo sites.
Sakai really doesn't have "demo" sites outside of the SCA's. And many of
the SCA's are more like the "Sample School" than a demo.

I'd expect that a demo site will:
- Have a clean set of data
- Are routinely *restored* back to the initial state (like
http://www.opensourcecms.com/) so any data doesn't mess it up at least
daily, possibly more often.
- Allow the user to easily login to all roles and configure all aspects,
though Sakai is hardly easy to administer
- Is running a "tested/stable" version, and will not have any significant
bugs that would cause a negative in the user experience

I expect a QA site will
- Retain data, at least until the next QA cycle, where it will either be
cleaned or converted
- Will be generally what you get in an OOTB install
- Have access to most roles, with limited access to admin so that someone
doesn't delete something important (like templates) while testing is going
on
- Are probably unstable, maybe down, or may have have significant bugs

So I guess what I'm saying is that there is "some" value to making the QA
easier to figure out, but we really could more use a demo site that has a
more specific purpose distinct from the QA's.

I guess trysakai and other SCA's already run something similar to Moodle
http://school.demo.moodle.net/ and Canvas' test school site. That's what
you'd need something above and beyond for.

4) I agree with his points that even finding these QA's for both OAE and
CLE are quite difficult. I have to use google to search for "sakai test
instance". Most people are going to want to look at the main webpage click
on "Sakai CLE -> Try Sakai CLE." Then there's some text there about needing
to install it? The page says there's a hosted trial for end users but I
don't see it? Which one is it?

It seems like this page should list:
- The demo instance
- The link to the QA instances
- The link to the SCA's

For the OAE it feels even worse. There's a small button to try it, and no
mention of any server. It says you can try it with the java webstart but no
real directions about that.

Okay so I download it, run it, wait about 5 minutes, click through at least
4 security warning windows, click Launch. Click to allow access,  Wait
another couple minutes . . . Then what? A blank window comes up that says
"Launch Nakamura".

So I completely agree that actually figuring out how to *try* either
instance of Sakai is really difficult. ;)

And now I can't close the "Launch Nakamura" window. Ugh! :)

On Mon, Apr 30, 2012 at 7:30 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> Ok maybe I wasn't entirely clear in what I was referring to.
>
> I'm not talking about sending people to the QA servers as their first
> experience, I'm talking about improving the out-of-the-box install that
> someone can run up themselves, either via source or demo, or see on the
> nightly build servers.
>
> What I did mention was that BOTH the out of the box install, and the QA
> servers, do not list ANYWHERE how to actually login to the system. People
> need to go elsewhere to figure that out. The QA page does mention creating
> an account but people shouldn't have to do that to get started. (Side note:
> I actually don't understand why the admin password for the QA servers is
> different to the normal admin password?)
>
> And the default gateway page does not list ANYTHING about how to login.
> People get the system up and running and then are like, "ok, now what.
> Let's click around and see if we can find something. Ah, new account, that
> sounds like it might be it. Ok I'm in, now what do I do? And, how do I
> administer this thing?"
>
> We need to make the very first impression a good one.
>
> This is what I meant that we should do:
> 1. Improve the HTML page that users see on the gateway. This would include
> info about how to login.
> 2. Remove some redundant links on the left nav and add the info they
> contain onto the front page.
> 3. Create two new accounts by default, without requiring any additional
> configuration. For argument's sake, call them 'student' and 'instructor'
> with the password being the same. Add these users to a site. Also provide
> the info about these two accounts on the front page.
> 4. Potentially improve the myworkspace info page in a similar manner.
>
> This does not require webservice scripts.
>
> I understand the SCA's reason to ensure their own pages are up to date.
> But we don't funnel everyone that comes along into using an SCA and what
> people get when they start up Sakai on their own machines should be a good
> experience.
>
> It's not a lot of work to do this. And I will do it. In my own (unpaid)
> time. I am just asking for others input on how best to go about it, and
> potentially have someone with a bit of design skill work with me.
>
> This is a valid concern. The guy I was talking to on that Facebook thread
> works for Netspot which was recently acquired by Blackboard. He posted
> about this issue a number of times over the past few years, also mentioned
> in that thread.
>
>
>
>
> On 01/05/2012, at 2:06 AM, Matthew Jones wrote:
>
> I also think that keeping these updated without someone paid in charge of
> this would be more of a challenge. If you look at the current static html
> welcome pages I referenced that haven't been updated in ~3 years, nearly
> all of the links on them are broken.
>
> Imagine if we had to keep java files or web service scripts updated. ;)
>
> For the SCA sites they have a important reason to making sure these are
> updated. The day something breaks on trysakai we are investigating it.
>
> Try some of the links on
> http://qa3-us.sakaiproject.org:8086/portal
>
> :)
>
> On Mon, Apr 30, 2012 at 11:59 AM, Matthew Jones <matthew at longsight.com>wrote:
>
>> Many SCA's like you said have a "demo experience" to sell the instance.
>> Like for Longsight someone can signup for
>>
>> https://trysakai.longsight.com/
>> https://trysakai29.longsight.com/
>>
>> And they get enrolled in a few sample course and project sites with
>> pre-populated data. I think it's the same for rSmart
>> rSmart: https://mysakai.rsmart.com/xsl-portal
>> and
>> Unicon: https://testdrivesakai.com/portal
>>
>> . These are either populated through webservices, database dumps or java
>> classes like the "SampleUserDirectoryProvider". Since the foundation (as
>> you mentioned) doesn't have any staff or developers, and writing something
>> like this takes substantial time, it's typically not something that gets
>> any priority since it already does exist in some form though their process
>> may not be public.
>>
>> I'm all for doing things to improve the efficiency of the QA process on
>> the QA servers, but I don't think we should be using our nightly QA
>> instance(s) as the the user facing demo's for what Sakai is capable of.
>> These are significantly more likely to have bugs and other issues which
>> could negatively influence the experience.
>>
>> If the foundation felt it was useful to hire a developer (or pay a
>> developer) to setup a stable instance with demo data, that I could see
>> happening, but I'm not sure of the ROI on that investment.
>>
>> On Mon, Apr 30, 2012 at 11:36 AM, Steve Swinsburg <
>> steve.swinsburg at gmail.com> wrote:
>>
>>> I think we need something in between having 1000 additional users and
>>> just admin. Like two extra users enrolled in a site, an instructor and a
>>> student. On by default.
>>>
>>> So then you can quickly jump in and use it but dont have to delete 1000
>>> users if you want to then do something ereal with it.
>>>
>>> We need to lower the barrier for getting up and running with a simple
>>> demo. And make it prettier.
>>>
>>> cheers,
>>> s
>>>
>>>
>>>
>>>
>>>  On Tue, May 1, 2012 at 1:29 AM, Matthew Jones <matthew at longsight.com>wrote:
>>>
>>>> I think for part #1 and #2 these users already exist, but not many
>>>> people *know* about the SampleUserDirectoryProvider that has been around
>>>> (in it's current form) for over 5 years. Most people know about admin, but
>>>> this provider (which all of the QA servers use because they start up with "-Dsakai.demo=true")
>>>> provides:
>>>>
>>>> * 1000 sample students with the username of
>>>> student0001-student1000 (all password sakai)
>>>>
>>>> The first 10 or so students have "realistic" names (some of them i18n),
>>>> the rest are all generic.
>>>>
>>>> * Sample instructor (instructor/sakai)
>>>> * A sample ta (ta/sakai)
>>>>  * Infinite other users (any user name that starts with test and the
>>>> password Sakai).
>>>>
>>>> The big advantage of this is if you use the "instructor" user you can
>>>> create a course site, add a roster and get all 1000 students enrolled in
>>>> it.
>>>>
>>>> I use this all of the time, though it probably *would* be more useful
>>>> documented on the front of the QA pages.
>>>>
>>>> Previously, the "welcome page" and other info was stored at
>>>> https://source.sakaiproject.org/contrib/qa/trunk/. I'm not sure if the
>>>> QA process is organized but I remember when I was running a QA, Alan/Seth
>>>> did direct me here to update content. Though it looks like the last change
>>>> here was years ago.
>>>>
>>>> [1]
>>>> https://source.sakaiproject.org/svn/providers/trunk/sample/src/java/org/sakaiproject/provider/user/SampleUserDirectoryProvider.java
>>>>
>>>>
>>>> On Mon, Apr 30, 2012 at 7:45 AM, Steve Swinsburg <
>>>> steve.swinsburg at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've just been having a discussion with a member of the Moodle
>>>>> community about how the default Sakai front page isn't really that
>>>>> exciting. This applies for both the default QA page and the normal install.
>>>>> I tend to agree and think we can do better.
>>>>>
>>>>> Some thoughts:
>>>>> * We could provide some info about how to login straight away.
>>>>> * We could also provide some more demo accounts, with users added to
>>>>> sites like the mercury site, and have them available on the front page as
>>>>> well. This would be in line with the OOTB uPortal install.
>>>>> * Maybe some more info about what you'll find inside.
>>>>> * A few images wouldn't hurt.
>>>>> * We could drop some of the pages on the left (like features and
>>>>> training) and incorporate those onto the front page.
>>>>>
>>>>> Compare:
>>>>> http://qa.moodle.net/
>>>>>
>>>>> And:
>>>>> http://qa3-us.sakaiproject.org:8086/portal
>>>>>
>>>>> I'd be prepared to do any code mods required if we can get a UI person
>>>>> involved as well, perhaps Gonzalo? We have made a good move with the
>>>>> neoportal, lets go a little further!
>>>>>
>>>>> https://jira.sakaiproject.org/browse/SAK-22122
>>>>>
>>>>> cheers,
>>>>> Steve
>>>>> _______________________________________________
>>>>> sakai2-tcc mailing list
>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>
>>>>
>>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20120430/9751a773/attachment-0001.html 


More information about the sakai2-tcc mailing list