So building on this,
Here's a rough architecture of pages
# Login screen
* oauth: google / openid, facebook, twitter etc
# Gallery page ( default page )
* Pagination
* Categories
# deployable template screen
* Rating / 'liking'
* Links to templates
* Click to view / (edit if owner)
* Download
* CommentsS
# template screen
* Rating
* Download
* Click to view textarea/ (edit if owner)
* Comments
* Used by ...(deployables)
# New template screen
* Upload button
* Edit from boilerplate in textarea
# New deployable screen
* Upload button
* Edit from boilerplate textarea
* Select template from gallery populated list
==============================
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
On 9/06/12 4:29 AM, Scott Seago wrote:
On 06/08/2012 01:53 PM, Michael Orazi wrote:
>
> ----- Original Message -----
>> On 06/08/2012 09:24 AM, Hugh O. Brock wrote:
>>> Yeah. We have to do this -- it's a blindingly obvious way to
>>> generate
>>> community interest and a real benefit for users.
>>>
>>> I've asked Francesco to head up the effort of getting the thing
>>> built. We can host it on the Redmine machine for now -- if it gets
>>> bogged down with too many users, well, that goes in the category of
>>> problems we'd like to have.
>>>
>>> Andy Fitz, can you help with the design? I'll then appoint someone
>>> to
>>> help Francesco get it coded up.
>>>
>>> Good stuff...
>>>
>>> --Hugh
>>>
>> I agree with everyone else here -- it is an excellent idea. It will
>> require one change to the deployable definition (and possibly a
>> related
>> change to the image model) that we've discussed in the past -- this
>> may
>> be the actual motivator to get it done. Currently deployables
>> reference
>> image by UUID, which makes them completely un-shareable. For this to
>> work we need to change the deployable definition to allow referencing
>> images by name. Since we're sharing deployables with templates, it's
>> actually template name we'd want to use.
>>
> It might be quite interesting to be able to refer to template via a
> url (real or not for now).
>
Sure. This is one case where the "portable" format may differ from
what we end up with in the database once imported. With a "portable"
deployable file imported into conductor, if the template is referenced
by URL we'll need to pull the template into conductor at the same
time, since we need it locally to build. Once that's done, the
in-database representation of the deployable would then point to this
imported template (by name?) rather than the URL alone, although we
may also want to keep the URL around so we know where we got it -- to
eventually give alerts if something is out-of-date, etc.
>> There are a bunch of implementation edge cases to work through here
>> --
>> since it's valid to use the same template more than once -- i.e. more
>> than one image that happen to use the same template, the template
>> name
>> will not uniquely identify an image. When you take a set of
>> templates+deployables that were shared and import/build/push the
>> templates and then import the deployables, you could end up with a
>> situation where a deployable identifies a template/image by a name
>> that
>> maps to more than one image in the system -- either because the same
>> template has been used more than once, or because there are multiple
>> templates that happen to have the same name. We'll have to come up
>> with
>> some way to resolve this, but the answer isn't obvious to me at this
>> time.
>>
>> Scott
>>
>>