The baserock UI - meetup notes

Pete Fotheringham pete.fotheringham at codethink.co.uk
Mon Mar 9 09:43:00 GMT 2015


Replying so we have a readable copy in the ML Archive (the item at 
http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-February/011200.html 
isn't)

On 06/02/2015 15:12, Mike Smith wrote:
> This is my write-up of the discussion from the Baserock meet up on 5th
> February concerning the user interface of Baserock.
>
> i will first go over the problems that where discussed followed by the
> actions and potential solutions that where arrived at through further
> discussion
>
> It is my intention that this e-mail be commented on with counter
> arguments to the problems, additions to the list of problems, addition
> of any problems i have neglected to include on this list, and of course
> discussion addition alteration and any other communication related to
> the potential solutions that have been discussed.
>
> *Problems with the UI*
>
> The largest thing to be discussed was the entry level to using Baserock,
> and the sharp learning curve. as a comparison people where asked how
> long it took for them to feel they could call themselves "productive"
> with Baserock. the reported times ranged from 3-4 days upwards getting
> towards nearly 3 weeks in some cases.
> This was due to the simple fact that the Baserock community are ,almost
> all, very familiar and skilled with Git. And the assumption has been
> made that users of Baserock would be equally as skilled. This in many
> instances is not the case. A new starter to Baserock must first learn
> Git, and then after they have learnt Git to a reasonable level, must
> then proceed to learn Morph, which extends on Git, but often not in ways
> that would be expected by a novice user. For example, branch handling in
> Git and morph are two separate things. checking out and altering a Morph
> branch does not necessarily mean that the related Git branch has also
> been altered, this can lead to situations where the user is sure that
> they have created and committed a new branch, but have in fact done
> nothing other than local changes.
>
> It was also pointed out that much of the terminology and short cuts used
> for the community can be confusing for a new user. for example the
> reference to a Sha1 of a branch rather than a fully qualified name of a
> branch will lead an inexperienced user to simply leave this alone as it
> is an un-known to them and best left alone.
>
> *Solutions to Problems*
>
> * Allow morph to be used /without/ workspaces. this reduces the
> complexity of the overall system and removes the need for branches and
> checkouts.
>
> * Get rid of push and Pull in morph and add the ability to commit / add
> Binarys
>
> * Morph Build and Deploy should by default use "Git HEAD"
>
> * Create some use-case storys. these should act as instructions and
> how-to's of various common scenarios. I.E.
> "I am in situation X, I need to be in situation Y, to do this I did the
> steps A,B,C. there was a potential to use option D in C's place. But in
> this case C was the simpler approach"
>
> * These how-to's /*Must be tested by people outside of the current
> Baserock community*/ as an acceptance criteria to them fulfilling the
> need for a guide that any computer user can follow.
>
> * Morph should potential have a one command "build a default generic
> Baserock image and deploy" so that users can quickly get up and running
> with the system.
>
> * Potentially look into creating an online interactive tutorial for
> Baserock to familiarise the new user with the set-up and use of Baserock
> in a safe environment ( The inspiration for this was taken from the
> Docker site at https://www.docker.com/tryit/ )
>
>
>
> _______________________________________________
> baserock-dev mailing list
> baserock-dev at baserock.org
> http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/baserock-dev-baserock.org
>




More information about the baserock-dev mailing list