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