----- Original Message -----
From: "Francesco Vollero" <fvollero(a)redhat.com>
To: aeolus-devel(a)lists.fedorahosted.org
Sent: Wednesday, June 20, 2012 11:41:52 AM
Subject: Re: ACA Side Topic - Proposal:
templates.aeolusproject.org
Il 6/20/12 3:45 PM, Matt Wagner ha scritto:
> On Tue, Jun 12, 2012 at 04:46:36PM +1000, Andy Fitzsimon wrote:
>> So building on this,
>>
>> Here's a rough architecture of pages
>
> Sorry for not responding sooner. I've been kind of eagerly awaiting
> your
> response, and Justin's reply made me realize that it's been sitting
> in
> my mailbox for a week. :-[
/me like Matt.
>
>> # Login screen
>> * oauth: google / openid, facebook, twitter etc
>
> As a login screen, I think this is good.
>
> The placement in this set sort of implies that you need to log in
> before
> you can do anything. I had kind of imagined that 95% of people
> would
> "just" grab a template, and only 5% of users would actually create
> any.
> So I think requiring login for normal operation would just be a
> barrier
> to entry. (I'm not sure if you're actually suggesting that they
> should
> have to log in before downloading templates and whatnot, though.)
>
> Can you actually use GitHub as a login source? That would be neat!
>
It's already done the authentication system with all those things.
We've
the needed gems configured to manage them.
>> # Gallery page ( default page )
>> * Pagination
>> * Categories
>
I was thinking, and I did in the model, to use the *Tag* element to
caracterize an *Entry* so it will be easy to search within tags
Would I be able to search based on the template submitter's name or follow a
particular person who submits templates I like/use a lot?
> I like the graphic for single image versus multi-image
deployables.
>
> By "Categories", do you mean the Newest/Popular/Highest-Rated sort
> of
> categories you show, or do you also envision a more hierarchical
> layout,
> e.g., "Web apps", "Financial apps", "Game servers",
etc.? (Those
> are
> terrible categories on my part, but you get the idea.)
>
> My fear here is that, initially, I don't think there will be any
> templates. We'll seed a few, and hopefully others will come along
> and
> contribute a few. But I think, even if the project gets some
> traction,
> it will be a while before we have any great number of templates. I
> think
> categorization is a great idea, but I worry about spending too much
> time
> on it if the categories are just going to be empty.
>
>> # deployable template screen
>> * Rating / 'liking'
>> * Links to templates
>> * Click to view / (edit if owner)
>> * Download
>> * CommentsS
>
Yeah, that can be feasible as well. At the moment I added the voting
system managed by mysql trigger, so for each vote we gonna have the
avg
rating.
> I like this view. A few thoughts:
>
> - The names "Deployable" and "Template" are maybe not the
clearest
> things we could use. Though I imagine that using different names
> than
> in the app would be terribly confusing, and I hardly intend to
> suggest
> that we should change the names we use in-app again. I wonder if
> there's something slick you could do with icons here, to make it
> clear
> that a template described how to build an image, whereas a
> deployment
> was how to launch one or more images built from templates?
>
Perhaps a simple workflow (block) diagram on the login page (or after the login page)
might help? IMHO it matters less what we call "Deployables" or
"Templates" and more that a user can identify these elements in his/her workflow
and use them correctly.
> - For the "Download" and "Clone" buttons, I
have this baseless
> feeling
> that the ordering should be flipped. I tend to expect the button
> on
> the right to be the "default" action. (Maybe something with
> coloring
> could help too?)
>
> - I had to stop and think for a minute what "Clone" would do.
Ditto here.
> I like the
> idea, though I don't know if it should be a "Version 1"
> requirement.
>
>> # template screen
>> * Rating
>> * Download
>> * Click to view textarea/ (edit if owner)
>> * Comments
>> * Used by ...(deployables)
>
> Looks good! Though with the same comment about download/clone as
> above.
>
>> # New template screen
>> * Upload button
>> * Edit from boilerplate in textarea
>
> I like the from file + from URL options.
>
> I wonder about the utility of editing a boilerplate template. It
> seems
> like we'd want people to upload existing, tested templates, while a
> "edit this boilerplate" form would invite people to make it up on
> the
> fly.
>
> Sidenote: This makes me realize that we probably need to *validate*
> these templates when they're uploaded, both for syntax and to make
> sure
> that they reference something useful.
+1 for validation. Maybe we could do some basic syntax validation and then give a template
a higher rating if we've actually managed to deploy and use the template. Some
affordance to allow the submitter to validate the template on upload would be great.
>
>> # New deployable screen
>> * Upload button
>> * Edit from boilerplate textarea
>> * Select template from gallery populated list
>
+1 even if the most logical way will be to do cut and paste of the
template.
Currently I'm thinking to have also the opportunity to be real
templates
in order to put straight the URL in conductor with parameters in the
url
to substitute the variables for the specific template.
> I missed this screen, but this sounds good, except for the
> boilerplate
> comment above.
>
>> ==============================
>>
>>
>> There is some potential duplication of features here for what
>> would
>> make a perfect conductor start-here-page.
>> Imagine being greeted with a screen that says:
>>
>> "new template (upload/edit)" and "select from templates
gallery"
>>
>> the "select from templates gallery" - no idea yet on how to best
>> present this
>
> Yes! Loving this idea. Or at least incorporating parts of this into
> our
> app.
+10
>
> -- Matt
--
Francesco Vollero
Software Engineer Aeolus Project