launchpad-dev team mailing list archive

[David Farning <dfarning@xxxxxxxxxxxxx>]

CCing Luke and Bernie (our fearless leader of our infrastructure team)

> By "the rules", Curtis just meant the licensing on the images (i.e., on
> the visual identity of Launchpad.net), as I talked about in another mail
> in this thread.  The code is indeed open source, and you can run
> instances.  Naturally, our hope is that you'll go with Launchpad.net;
> I've been chatting with lfaraone in IRC about making sure that the data
> is exportable via the APIs -- lfaraone can give details on that.
>

Thanks for the additional information.

After our last conversation.  I dropped my objection about needing to
set up our own test instance of  LP and practice exporting the Sugar
Labs data to it.

Currently, I feel blocked by the hurdles new users users must jump to
get back to the other SL sites.  I did a small usability study with
some teachers at a local school.

It was not meant as a usability study.  My nieces and their friends
took my six XOs to parent teacher conferences so they would have
something to do while their parent talked to the various teachers.
The sight of a group of 1st, 2nd, and 3rd graders playing with the XOs
created quite a stir.  So, like any other pointy-headed admin type, I
decided to do some usability tests.  Luckily, the kids had set up
collaboration so I didn't have to walk parents and teachers through
that mess:)

The top Launch Pad issues were:
1. Inability to get back to the other SL sites. Specifically, the
Sugar Labs logo in the upper right corner should like back to
[wiki,ww].sugarlabs.org.  (The same is true for
activities.sugarlabs.org )

2. Getting lost by following links to stuff the Sl does not use.  The
links to translations and branches were particularly troublesome.

3. Getting lost in Ubuntu.  This is a longer term problem.  But,
several times users would do something to leave the SL portion of LP
and get lost in the larger ubuntu LP.  There were sometime no
breadcrumbs to get back.

I have expressed these concerns to Luke in a snippet of a email thread
we had.  (quoted below)

Now that the specific actionable improvements section is over:)  The
over all feeling regarding Launch Pad was very good.

My recommendation would be that Luke et. al.  move the SoaS launchpad
pad stuff to https://edge.launchpad.net and spend a couple weeks (or
more likely months) working with the LP developers, SoaS developers,
and SoaS users to resolve usability and workflow issues.

But, if we migrated today the world wouldn't end:)  So, as I told
Luke, I am going to step back and watch.

david

--------------
My primary concerns now are that we must be able to:
1. Customize the *  Overview * Branches * Bugs * Blueprints *
Translations * Answers * menu bar.  As it stands, the Translations
link is confusing.  Either the translation team must agree to move to
rosetta or the link must point to pootle.sl.o
2. We must be able to add a header such as we have on the other *.sl.o
service enabling. Currently, once a user get into lp there is noway
back to the rest of the SL services.
3.  This migration should be brought up on iaep.  Currently it feels
like you and Caroline are pushing for this migration without asking
anyone else or considering the long term ramifications the migration.
--------------