[IAEP] [Sugar-devel] [DESIGN RFC] In-Sugar Introduction (was: Onboarding)
sam at sam.today
Sun Jan 3 06:04:08 EST 2016
Thanks for the responses to my proposal.
Through reading, I have realized that it was very arrogant to imply that
this was *the* onboarding for sugar. Onboarding is more than any
individual tour, it is the journey that users take before they can get
value from Sugar. This journey is going to compose of multiple parts.
So how does the current landscape look like (in my opinion)? We have lots
of great content. There are Iain's slideshows and Training activity among
many others. However many of these systems take time out of the users
control. They require the user to do what the content says for 10 minutes
or multiple hours respectively. This is perfectly appropriate in some
situations, and these are both easy to read/understand systems for
delivering good content.
However, users not all users are in the situation to use those mechanisms.
Some may be eager start working on their systems, and be dismissive of the
tutorials (users which the in-sugar intro would benefit from the contextual
hotspots when they are lost). Others may be forgetful, or not in a good
state of mind during less interactive training, and benefit from the
reminders. Some users may be evaluating sugar, and would benefit from
getting started on their own adventures sooner, which would be facilitated
better by the in sugar introduction.
I have updated my proposal to include F6 frame activation, help activity,
shutting down. The link is now with https, and hopefully less line breaks:
I have not updated it to include a better way of displaying progress. I
agree with Quozl that it would be beneficial, however I am completely
unsure of how to visually design it. Suggestions are always welcome.
Regarding teaching hotkeys over mouse based interactions, I feel that this
is not suited for a tour (unless it a tour of vim that is). I don't want
to scare the user away in their first sitting, by trying to make them
remember every single key combination. I also feel that hot keys can could
be more easily explained by a poster as Tony suggested initially. I will
attempt to create a poster to demonstrate this idea.
Regarding translations and the promise of iconography: I believe that
iconography is great. But I think it is a very hard task to generate
images that represent the complex ideas in the sugar UI, a task above
Tony also raised the issue of users varying level of familiarity with
computers in general. I have probably aimed this introduction proposal at
somebody who has never used sugar, but is familiar with basic computer
manipulation (how to use a mouse, how to "mouse over" something, how to
click buttons) as well as assuming that they may be familiar with basic
types of applications (do I want to launch "Write"? It is probably like
MicroSoft Word, so yes). In order to work with users without this
knowledge, I would need to change the introduction content very much, and
maybe even the mechanism. I would probably need to also help the user
through the intro screen (where name and colour are setup) as well.
However, I plan to aim at the first subset of users, then it may be
possible to re-use the technology for the latter subset of users. It is a
completely different debate about how to teach via the screen somebody to
use a mouse though.
On Thu, Dec 31, 2015 at 11:33 PM, Iain Brown Douglas <
iain at browndouglas.plus.com> wrote:
> Hi Sam,
> This is a fine proposal and I cannot fault your 15 points.
> One comment, some are essential, "first ten minutes of use issues" and
> some might be seen as essential to getting productive.
> Of course onboarding runs at many levels, and may be significantly
> different for different user groups.
> Elsewhere on this thread you asked for feedback on two items:
> 1. adding references to the F6 and other Function keys. I say yes, as I
> try to introduce Function keys early - it is more easy to teach small
> children key presses than mouse movements.
> 2. I think a hint to Help Activity would be good.
> Without wanting to detract from your proposal, it is interesting that
> https://www.useronboard.com/ itself uses a slideshow technology.
> In general I like this, as it allows the user to speed read the material
> and salient points are more easily revisited in a slideshow than a
> youtube or screencast type presentation.
> My own New to Sugar concept lives here:
> I would very much like to hear detailed critical response to my work.
> This might give us both some insight into avenues that might be most
> appreciated by users.
> Kudos to all involved in champion work on www.sugarlabs.org btw.
> All the best in 2016,
> On Sun, 2015-12-27 at 17:20 +1100, Sam P. wrote:
> > Hi All,
> > Sugar has a novel user interface, with lots of beautiful and logical
> > things. However, there are some important elements (such as the frame
> > or journal) that are not familiar or intuitive to new users. This is
> > an issue, as sugar currently relys upon exploration as our only user
> > onboarding strategy.
> > The un-intuitiveness of our ui comes up every now and again. I
> > previously conducted a small and probably skewed survey, however the
> > lack of user onboarding and the effects of that (how users did not
> > understand the interface) were apparent. It's also written about in
> > Jeff Atwood's (old) article "the Sugar UI", where he says, "I have to
> > admit that I didn't find the Sugar UI particularly intuitive or
> > discoverable, even after using it for 10 minutes and learning the
> > basics."
> > Please have a look at my design proposal to add help for new users
> > . No implementation has been done (as you would expect due to the
> > time in the release cycle), and comments would be appreciated to
> > create a great design before even thinking of implementing.
> > Thanks,
> > Sam
> >  http://www.sam.today/blog/sugar-onboard-design.html
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IAEP