Stab at a toolkitchen diagram

[Alex Komoroske]

Hi everyone,

I've been trying to figure out how to express what toolkitchen is in a diagram. There's a lot of stuff to get across: layering, how the polyfills fit in, how components fit in--and finally, what everything is called . There's also a lot of interaction between different bits that we'd ideally try to get across.

Here's a random non-prettified attempt (see attached png). Is it a total mess? Is it confusing?

--Alex

[Alex Komoroske]

Argh, here that is again as a proper attachment.

[Alex Komoroske]

Jeez, I really fail today. Here's a properly sized version.

[Eric Bidelman]

HD looks so much better :)

At first glance, I found this very busy and confusing. But the more I look at it, the more I like it. I get what you're trying to convey:

- the polyfills fill the native voids and form the foundational layer

- plug in batteries to your components with the kernel. Its optional, so makes sense

that green extends into red.

- the whole thing is a la carte: why some segments are larger/smaller than others.

However, we're on the same mental track. I'd like to hear from others to see

if this makes sense to them.

Can an we avoid "widgets"? "Toolkit components" sounds better.

I'm even imagining this as a interactive panel. We start with the clean version on the left side. Hovering over sections flys them out, showing everything underneath.

--
You received this message because you are subscribed to the Google Groups "Toolkitchen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to toolkitchen...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alex Komoroske]

On Thu, Apr 18, 2013 at 6:02 PM, Eric Bidelman <ericbi...@google.com> wrote:

HD looks so much better :)

At first glance, I found this very busy and confusing. But the more I look at it, the more I like it. I get what you're trying to convey:

- the polyfills fill the native voids and form the foundational layer

- plug in batteries to your components with the kernel. Its optional, so makes sense

that green extends into red.

- the whole thing is a la carte: why some segments are larger/smaller than others.

However, we're on the same mental track. I'd like to hear from others to see

if this makes sense to them.

Can an we avoid "widgets"? "Toolkit components" sounds better.

Ah, yeah, I meant to change that. Thanks for pointing out. 

I'm even imagining this as a interactive panel. We start with the clean version on the left side. Hovering over sections flys them out, showing everything underneath.

Yeah, I did this diagram in Illustrator. After some tweaking I was imagining I'd export as SVG and then hand edit from there with more dynamic effects to help clarify things as you interact with it. 

[Eric Bidelman]

Let me know if you want help!

Digesting this some more, I think you should ditch some of the (smaller) purple

app boxes. It makes things unnecessarily busy. The goal of the diagram is to show

how the layers of Toolkitchen fit together. I think it's good to put some apps on top to 

show how they mix-in, but not as many as you have.

[Mike Lawther]

I'm not sure about all the extra 'app' and 'component' boxes. It seems like you're trying to cover various combinations of ways to build apps, but I start overanalysing and thinking 'how come an app can't go direct to native?'

[Scott Miles]

I'm impressed by the amount of nuance you captured in this diagram.

[Andrei Mouravski]

Big fan of the diagram, and I really like Eric's idea of an interactive panel.

One facet that could really hit people is another full height bar (or bars) on the left for roles.

So as a developer of web sites, I only really care about the top half of the components (the API they provide) and the web app.

A designer might care about a different section of the green and also some of the application.

An implementer might only care about the bottom half.

A component builder might care about about the kernel and platform.

A software engineer might care about the polyfills and ignore the applications, etc.

This would benefit a lot by being able to click different buttons to get different views of the same architecture. 

[Alex Russell]

Me too! It's really, really good. Might be useful to have some sort of vertical stack for how MDV plays with your app's data model, but that's the only thing I can think of that's missing.

[Alex Komoroske]

Thanks for all of the comments!

Here's a V2. 

Changes:

• Widgets --> Components
• Made the non-toolkitchen parts way more transparent so they don't crowd the diagram as much
• Made the "Your App" box be just another box like any other third party app: no label and very transparent
• Tightened up positioning of overlapping boxes (minor)

Andrei and Alex, I liked both of your ideas, but I couldn't figure out a way to include them without cluttering it up even more. :-/

If there are no other big suggestions, I'll get an SVG version ready tomorrow.

[Scott Miles]

Where's the V2?

[Alex Komoroske]

... I swear I'm actually a functioning human being.

Attached!

[Eric Bidelman]

Do we need a spot for <template>? It doesn't exist as a separate polyfill

repo but it's common across MDV and Custom Elements.

Toolkitchen Components ->Toolkit Components. At least that's what the docs are calling them.

I'm struggling with Toolkit Components being the same color green as the regular joe components™ that don't touch toolkit.js. What if you did a small gradient at the bottom of the green Toolkit Components that faded from the yellow kernel into the green?

[Alex Komoroske]

On Fri, Apr 26, 2013 at 9:08 AM, Eric Bidelman <ebi...@gmail.com> wrote:

Do we need a spot for <template>? It doesn't exist as a separate polyfill

repo but it's common across MDV and Custom Elements.

Yeah, I struggled with that. Do we have any plans to make <template> be a separate polyfill, or will it always be a weird semi-shared piece between custom elements and MDV? 

Toolkitchen Components ->Toolkit Components. At least that's what the docs are calling them.

Hmm, it seems confusing that we're using "Toolkitchen" and "Toolkit" in vaguely interchangeable ways. In my mind, "Toolkit.js" is a sub-piece of the larger Toolkitchen family of things. "Toolkitchen" in "Toolkitchen Components" is a descriptive modifier of "Components". 

What was the reasoning for calling them "Toolkit Components" in the docs? I'm probably just not thinking it through clearly.

I'm struggling with Toolkit Components being the same color green as the regular joe components™ that don't touch toolkit.js.

Why? Some components are built on top of the yellow layer (that is, they rely on them) and others aren't.

 

What if you did a small gradient at the bottom of the green Toolkit Components that faded from the yellow kernel into the green?

I'd rather not introduce gradients to complicate an already complicated diagram, especially because what they'd communicate is basically the same as what the stacking already communicates. (Or again, maybe I'm just not thinking through this clearly).

[Eric Bidelman]

Naming has evolved over time, but here's where things have landed:

"Toolkitchen" / "Toolkitchen Project"

Is the full offering, including all the polyfill repos, toolkit.js, apps, etc.

It also represents the org page: https://github.com/toolkitchen/

"Tookit component"

Is a component that is super charged with toolkit.js (the kernel).

"Toolkitchen component" doesn't exist.

[Alex Komoroske]

On Fri, Apr 26, 2013 at 12:05 PM, Eric Bidelman <ericbi...@google.com> wrote:

Naming has evolved over time, but here's where things have landed:

"Toolkitchen" / "Toolkitchen Project"

Is the full offering, including all the polyfill repos, toolkit.js, apps, etc.

It also represents the org page: https://github.com/toolkitchen/

"Tookit component"

Is a component that is super charged with toolkit.js (the kernel).

In the future, hopefully people will build components that require toolkit.js. However, there will be no requirement for those to be hosted in toolkitchen proper. What we need is a term for the "official" components in the toolkitchen repo.

[Scott Miles]

Fwiw, we are planning on moving the 'components' out of 'toolkit/components' and into their own repo, like ... today.

The naming is a problem for us too. I think we landed on 'toolkit-ui' as our working-name.

The components we made to wrap (second and) third-party libs are still in 'pantry', while we continue to (vita-)mix metaphors.

[JZ JennyZhang]

hi, can you provide a link to toolkitchen or any other web component builders? thanks!

[Rob Dodson]

Toolkitchen is now known as Polymer. The best place to find out more is the Polymer site: http://www.polymer-project.org/

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/36f817f1-fc8e-4ad7-b5b6-78cd8cf87c20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JZ JennyZhang]

Thanks! What are the pros and cons compared to React, for building a builder for marketers to create quizes and other interactive ads, by dragging and dropping?

..........................

JZ | UX/UI Design Lead (Product Team, 6th Floor)

E: j...@offerpop.com

...

[Rob Dodson]

I think the primary benefits would be:

1. Familiarity - Polymer elements are written primarily in HTML, CSS and vanilla JavaScript. It's very easy for someone who is comfortable taking a design from Photoshop and slicing it up into HTML/CSS to start creating Polymer elements. React components are written entirely in JavaScript (I believe the CSS can be written in JavaScript as well) and requires learning a bit more of the framework to get something up on screen.

2. Shadow DOM - Polymer elements do a really nice job of scoping their CSS styles so they don't affect anything else on the page. This can be really ideal for a widget library because it essentially sandboxes each widget's CSS so they don't interfere with one another.