Prototypes Requirements

[codingdesigner]

Finally had some time to boil down my thoughts on what we initially need for this. We need:

1. Multiple style tiles
   • need to be able to explore different concepts
   • ideally it should be easy to convert the sass from the winning concept to be the 'master' sass
2. To collect components into pages
3. To collect pages into page groups (mini-sites)
   • ideally be able to navigate naturally within groups
4. To be able to A/B different pages / groups
   • create alternate versions of a page, or a section, or any grouping of pages
   • should be able to clearly show what's in each group (index page)

[Snugug]

1. Is there something about a git branching/merging model that doesn't work to solve this? Would it help if the current git branch was displayed in the SP Header?
2. Currently can be done simply by creating a new page and utilizing Handlebars' partial {{> partial-name}}. A different HTML template may be needed though for a prototype page.
3. Should this be folder based (groupings inside of the pages directory, or done through a config file? Maybe add a prototypes.yml file to handle this?
4. Showing an index of what's on each page may be a challenge, would need to meditate on how to accomplish that. How would you want alternatives handled? Appending A/B/C to the page name? A config file? How would switching between them work? Switching between groupings of pages can be just nav, but different versions of the same page may be challenging if we're not just displaying all of the page names, and potentially very so for different sections of a given page. How would you mark up a section difference? Would it be a special kind of partial? Would it just be easier to create a new page and have it work off of the page swapping method? With a keyboard, this could be accomplished with keystrokes, but how would it work on a touch interface?

[codingdesigner]

1. I feel strongly that git is not the solution for in-progress design review, or for presentations. Imagine swapping branches in a presentation to an art director or a stakeholder. I don't see that going well. And even if you are a git expert, A/B/C versions need to be available simultaneously for rapid review and decision making.
2. agree we already have this, and that solution is fine
3. I think we should go the config route. A flat file structure would make it easier to reuse pages, and would make interlinking them easier too. we can organize pages with some naming convention.
4. You misunderstand me. I want an index page that lists and links to the pages in a group, not to components on a page. These could be created manually like any page, but if we solve page groups in a systematic way then we could probably generate them. They really help in presentations.

[Snugug]

1. I feel very strongly that git is the only reasonable solution we have to multiple different directions on the same code base; hell, that's practically the definition of a Git branch.

I'm not suggesting that you sit in a presentation and swap branches around (although it would be easy to do as Grunt would just recompile everything). What I'm suggesting is having multiple copies of the repo checked out, all at a different branch, for the presentation only, all running off of different ports. You can throw them all up at the same time, they can all be played with at the same time, and whatever is liked the best can be merged to master without any heavy lifting on SP's end. In fact, the more I think about it, the more I like A/B testing that way.

I'm much more inclined to build a system that supports this workflow, including a way to display what branch you're on, than to reinvent the wheel when it comes to code branching and merging.

On Sep 15, 2013, at 1:59 AM, Mason Wendell notifications@github.com wrote:

I feel strongly that git is not the solution for in-progress design review, or for presentations. Imagine swapping branches in a presentation to an art director or a stakeholder. I don't see that going well. And even if you are a git expert, A/B/C versions need to be available simultaneously for rapid review and decision making.

agree we already have this, and that solution is fine

I think we should go the config route. A flat file structure would make it easier to reuse pages, and would make interlinking them easier too. we can organize pages with some naming convention.

You misunderstand me. I want an index page that lists and links to the pages in a group, not to components on a page. These could be created manually like any page, but if we solve page groups in a systematic way then we could probably generate them. They really help in presentations.

—
Reply to this email directly or view it on GitHub.

[codingdesigner]

I've been thinking about this today and I mostly agree with you. Presentations aren't the big hurdle here. I think what's keeping me from fully endorsing the branch method is that I want a streamlined creative workflow. As I'm designing I want to be able to see multiple versions of a thing at once to make decisions. That's not the time to check out two branches and spin up two or more servers. The solution here is obvious tho. I would just use sloppy code. Throw in what it takes to see it the way I want, and then clean it up into my design or into competing branches. I'm sure that's going to be the reality no matter what system we come up with anyway.

[Snugug]

I've introduced a sections.yml file for folder hirearchies, allowing you to add sections and build out sub-navigation for each main page inside of config.yml's sections: group. This should solve 3 more or less, or at least be a building block.

We can also do a prototype.yml to throw into a folder structure to determine what is available. We should discuss in-person next week.

Once that is solved, I think this is more or less finished

[Snugug]

Much of this is good to go for Style Prototypes 2.0. Specifically the ability to add multiple Style Tiles, create Pages, group Pages into mini sites (which you could then create navigation for to move around).

The only thing not implemented is A/B testing pages, how would you recommend going about doing that?