Winged Monkey

Jaromír Coufal jcoufal at redhat.com
Thu Oct 25 17:30:55 UTC 2012


Hello folks,

I was also feeling and saying (as Matt wrote few mails ago), that with 
Winked Monkey, we are going to duplicate part of Conductor and trying to 
avoid its difficult parts.
=
My idea about how we can deal with this situation in Conductor is based 
on user privileges and hiding sections, which user cannot access. Let me 
explain on simple example:

* Situation (based on Winked Monkey purpose):
- We have a user who doesn't (or shouldn't) care about creating images, 
pushing to providers, setting environments or pools, (...).
- User wants just to start and stop images, which he has on different 
provider accounts.

* One suggestion how we can deal with this situation:
- When I restrict user, that he can't create images, manage providers, 
realms, hardware profiles, (...) so he can just and only launch images, 
he won't be able to do anything else in the system. In the best final 
way, he won't be able to see any other sections he has no access to, so 
he will be able just to see section where: 1) are running instances and 
2) the other one with images he can launch. Nothing else. No providers, 
no realms, no hardware distractions.
- Furthermore, having set some default realms, default hardware 
profiles, (...) and if user would not be allowed to change them, he will 
have nothing to set up in launching process.
- In the end he will just see running instances and images he can run. 
After hitting launch button, his instance will "automegicaly" run, 
because he can't set up anything.

And that's actually everything what Winked Monkey should provide, right? 
I think we can get similar effect in Conductor.
=
Further more, it's not that simple how it seems (if I get it in a right 
way).

There are three steps, which each user always needs to follow if he 
wants to manage provider images:
1) Connect to provider account - add account details to our application 
(our system needs to connect to the provider so we can manage his instances)
2) Import images from selected provider account (otherwise we have 
nothing to manage)
3) Start/Pause/Stop images.

So both Winked Monkey and Conductor always need to cover these steps, right?

By creating type of user in Conductor, who can only:
1) add provider account,
2) import images from provider,
3) start/Pause/Stop
... we will have this requirement satisfied. And he will see nothing 
else (regarding permissions).

In Winked Monkey, as I found out, there is not even counted with these 
necessary steps (talking about steps 1 and 2). Adding these features, we 
are slowly going to lighter version of Conductor.
=
What I really like about Winked Monkey is, that we started to think 
about UI from different point of view and started to care just about 
users who are running images. Which definitely can inspire and help us 
to improve UX.

Another value I see in Winked Monkey project is, that we will approach 
broader audience and community of users - those having just few images 
across different providers.
But my question is, if this segment of users is big enough? Because from 
my point of view, being individual (or small company) running just few 
instances, I am usually choosing one provider and running all instances 
there - in this case I would not search for application unifying UI for 
running instances.
(maybe I am wrong on this one)
=
Having talks about this particular type of users and creating muck-ups 
for their use-cases is definitely valuable for us. I feel, and I am 
sorry to express my worries, that having stand-alone application as 
Winked Monkey is (especially implementation and maintenance) would 
consume lot of effort and resources. I think, that we can achieve 
similar result with improving Conductor for less effort.

-- Jarda

-- 
Jaromír Coufal

Interaction Designer
Red Hat Czech s.r.o.

Mobile: +420 724 595 508
E-mail: jcoufal at redhat.com
IRC: jcoufal at #cloudforms-ui, #aeolus, #brno





More information about the aeolus-devel mailing list