What are our brand principles?

Design
1

Does Ember have a short list of brand principles?

If so (I genuinely don’t know), could someone point me to them? If not, maybe we could kickstart a process of figuring them out.

I’m asking because as more folks get involved in the Ember project, having a short list of brand principles to refer to could help ensure that all our web properties and projects stay aligned & communicate the things we care about.

I thought about this because recently I’ve been working on Addon Docs, and I’ve done most of the design for that myself. But I want to make sure the design represents Ember’s brand – but to do that, I need to first know what Ember’s brand is. The same is true for others working on the homepage & other sites in our ecosystem.

What is a brand?

I am not a trained designer and would love some input from those with more experience, but here are some things I’ve learned over the past year as I’ve worked through branding issues, both for my own company and for clients:

  • Values are not the brand. Ember has some well-defined values like “Stability without stagnation” and “A framework for ambitious developers”. These influence the brand, but are not the brand.
  • A logo is not a brand. We can define & refine our brand without changing our logo.
  • Branding is a person’s gut feeling about a product, service, or company. You can’t control the process, but you can influence it. [1]
  • Branding is not what you say it is – it’s what they say it is. [1]

What I’d like to see is us come up with a list of 3-4 attributes that embody Ember’s brand. That’s a short list that anybody in the community can use to ask if their project aligns with.

Take a look at Airbnb’s [2]:

image
image1924×998 53.2 KB

These words are about how people feel about Airbnb. So when thinking of our own brand, how do we want people to feel about Ember?

My take

I started thinking about this and wanted to jot down some notes.

Point 1

I started with “Stability without stagnation”, perhaps the most defining value of Ember. So, how does SWS make me feel?

It makes me feel comforted - like I won’t get left in the dust. I know I’ll be able to take advantage of all the new cool JavaScript things in an easy way. I won’t be miserable working on a legacy app with outdated patterns or syntax, just wishing I could start from scratch.

  • comforted, secure, stable, safe, protected, supported, confident, guided, guarded, escorted, mentored, assisted, helped, accompanied

“Stable but not stagnant” is actually quite close to a brand principle.

It’s also helpful to discuss the “nots”, the things we don’t want people to feel about Ember. So if we say we want folks to feel “secure”, it doesn’t mean we want them to feel “locked-in” or “confined”

  • not stagnant, not locked-in, not confined

Point 2

Next, all the Ember apps I’ve worked on always felt modern and up-to-date, even if they were years-old. That’s an amazing thing. There is some overlap here with SWS, but “not stagnant” takes a defensive position on the “modern” question. I’d like some positive words (because a modern Ember app does, in fact, feel like it belongs alongside other contemporary frameworks).

  • modern, up-to-date, contemporary, current, advanced

And the nots:

  • not cutting-edge, not sterile, not fashionable, not trending, not hip

Point 3

One of my favorite things about Ember is its community. When I think about Ember, I can’t help but think about all the friendly people I know, how welcoming and encouraging DockYard was when I first got started with Ember, and how much I look forward to seeing everyone at conferences each year. Ember is also deliberate about being inclusive through initiatives like Women Helping Women.

  • friendly, welcoming, inclusive, caring, fun, warm, approachable

And the nots:

  • not weak, not delicate, not fragile, not yielding, not lax, not permissive, not overly tolerant, not compromising

Point 4

Finally, Ember makes me feel very productive. I trust the leaders who put thought into its architecture and design. I like that there’s a complete toolkit at my disposal, and there’s guide rails for each next step I take as I develop an app.

  • productive, trust-worthy, unified, integrated, all-inclusive, complete, thorough, in-depth, broad

And the nots:

  • not exclusive, not incompatible, not stifling

Summary

If I had to pull the trigger right now, I want Ember to feel

  • productive, but not overwhelming
  • modern, but not cutting-edge
  • integrated, but not stifling
  • stable, but not stagnant
  • friendly, but not compromising

I know I broke my rule of 3-4, but I’m spitballing here. Also, this list is part how Ember makes me feel today, and part vision for the future.

Your take

So, what do you think? How does Ember make you feel? How do you want it to make you feel? How do you want others to feel when they use Ember for the first time, or for 3 years?

Let’s get the discussion going!

Resources

14 Likes
2

When I think of the “Ember-versus” question, I often think that React’s genius lies in the fact that it has gotten developers to believe that the core problem with their React app is the fact that they have not gotten the exact right witches’-brew of libraries installed (oh, you’re having that problem because you’re using the wrong router, the wrong state-management solution, the wrong AJAX interface, etc.). So it’s very much easier for React to be “everything to everyone” while simultaneously disappointing most people in the actual developer experience.

What I love about Ember is that there is often One Right Way to do things and it actually works. It’s opinionated. It takes care of you as a developer. I think this is similar to Point 4 that you make, but is more along the lines of

  • Tools that work right now
  • All the things you need to write an app and nothing that you do not

And the nots:

  • Not afraid to provide guidance
  • No hype
  • No bullshit solutions.
2 Likes
3

I’d say that’s very accurate, Facebook as always understands their users psychology just a little too well

1 Like
4

I don’t know if I agree with this principle. There was certainly a time when Ember was cutting-edge: we had the first/best router, the first/best CLI, etc. Other projects copied Ember. Furthermore, there are still aspects of Ember/Glimmer that are cutting-edge: ES6 classes, TypeScript support, Glimmer rendering speed, ember-concurrency, mirage (to name a few).

I understand that there is a contingency within the Ember community that is sort of “fat and happy” with an ethos that might be expressed as, “Ember’s great! Yeah maybe it kinda sucks, but I really know it and it pays the bills!”

Personally, I’d prefer not to be in a community where we all sort of back away from being “the best, most forward-thinking framework on the planet” and shoot instead for “the least objectionable javascript framework,” or worse, “the framework that some boring people know and won’t give up.”

1 Like
5

Yep. Great points. “Not cutting-edge” was trying to get at the fact that we don’t futz with the latest new and shiny, just because. Rather, we are “timeless” and “durable” and “long-lasting.” Maybe there’s a better word.

1 Like
6

I dunno about you guys but I see a lot of similarities with how Ember works with Zen of Python. Specifically the There’s only one way to do it (TOOWTDI) or to expound it more from the zen itself: There should be one-- and preferably only one --obvious way to do it.

Very controversial and yet the Python community has embrqced this very well and the language arguably is the most popular globally.

1 Like
7

I definitely see what you’re getting at, though I’d say something like “Modern, not reckless” or “Modern, not hasty”

3 Likes
8

I also like “Modern, not reckless”.

1 Like
9

Yeah, lots of the current stuff in Ember really is cutting edge. Nobody else has a true opcode-based VM yet, and that lead is only growing as we move to a binary compilation format.

So no reason to be defensive. I think what you were really going for was “trustworthy”, as in “not just some kid’s random weekend project”.

To me, one of the words that has always come to mind is “engineering”, in the sense that I’ve worked in places with world-class software engineering culture, and when you come out of those places you know what serious engineering looks like, and Ember looks like that.

But I don’t actually think this is a great way to market to Javascript devs, for cultural reasons. I strongly reject the whole frontender/backender dichotomy and the elitism that goes with it, but it’s a fact that Javascript’s median developer is much less experienced than many other domains of software engineering, just due to the explosive growth of the industry. As fast as people are leveling up, newbies pour in even faster. This has always been a headwind for us, because we solve a lot of problems newbies don’t even know exist (like “how not to hate your codebase three years from now, after twelve different people have worked on it”).

6 Likes
10

“Built to last” may be a good slogan. Though you also need to try to convey that for software to last, that implies that it’s living and growing and evolving. Not static.

4 Likes
11

This is great. I’ve been thinking about how I feel about Ember…

Ember feels safe. When using it I don’t feel like I’m building a mountain of technical debt. At the same time, I don’t feel like I’m confined. You said “not confined” in the original post and that really resonated.

Ember is smart, but not a know-it-all. There’s no doubt in my mind that Ember has some of the best engineering in the JS ecosystem. However, it’s willing to borrow the good ideas from other frameworks if they make Ember better.

Ember is opinionated, but it’s not demanding. Maybe opinionated isn’t the right word, it’s more like “Ember is a good mentor”. It’s going to guide me into making good decisions, but ultimately it will leave those decisions up to me. That makes me feel like I can experiment when needed without having to take the rest of my codebase off a well trotted path.

3 Likes
12

Loving these replies.

Just want to point out that if we land on some of these brand principles, they can be “internal” to Ember; that is to say, if we want people to feel like Ember is “well-engineered”, we don’t necessarily have to put “Well-engineered” on Ember’s homepage.

1 Like
13

With productive in mind, I’d also note that it’s very empowering. The amount of stable and high-quality functionality I can produce in record time is simply amazing. Especially in the UI world.

2 Likes
14

I love this discussion! Thanks for getting it started @samselikoff.

This mentor idea really resonates with me. It’s a combination of the the strong conventions of the framework AND the support/guidance of the community. What I appreciate the most is that, like any good mentor, it’s relatively low ego. There is a lot of consensus building and working on shared norms, which means there is less room for rockstars/ninjas/other mythical developer creatures. Combine that with the pattern of acknowledging mistakes and transparently working to improve generally leaves me with the sense of it’s trustworthiness.

Along the lines of transparency, open is another word the comes to mind. It’s truly open source. It has a phenomenal RFC process. We know the drill here.

15

I’m pretty new to Ember, just doing it on side projects and as a hobby, but I’m loving it and I think this discussion is helping to bring some things into focus. To get the brainstorming going and find the right words and concepts, how about we for a short moment (just this post) think of Ember as a character. And I don’t mean Tomster, just some characters that in part represent what Ember is.

Ember is Optimus Prime. Ember is Mr. Miyagi. Ember is Captain Sheridan. Gandalf. Dumbledore.

Leading with competence while not trying to present itself as the new and shiny. And always, always trying to do the right thing.

Did I help the discussion? Probably not. But at least it helps me to think this way.

3 Likes
16

I have experience with design, especially from a branding and marketing perspective. I think the biggest concepts to promote Ember is how much time you save from having such a well-defined and tested stack. The biggest problem Ember faces is the Facebook PR machine in full swing behind React: being a developer as well I’m often approached by clients that say they want “React” mainly because it’s just a buzzword now. They have no idea that React isn’t just a view framework, or even any idea of what React is aside from it powering web apps.

To expand on the “Freedom vs Time” kind of thing: if you want to endlessly tweak, bike-shed and build your own framework, use React and cobble the parts together yourself. If you want something that has been well considered in terms of small and large projects with many stakeholders involved (e.g. frontend, backend, UX) then I found Ember allowed me the easiest path to launch in the smallest amount of time. If there’s some way to explain and show this to developers and non-developers a-like, then there might be some success there. The size of Ember’s dev ecosystem of add-ons is a valuable asset which again saves time and allows a lot of pre-built functionality “That just works™”.

My input would be that Ember is reliable — with updates and with dependability. Personally too I think being “opinionated” is a good feature. When I was looking for a SPA framework, I liked that Ember had its “one way” to do things, and I often found that it was smart/relevant enough for me. In contrast, I have been working with React/Redux, and so much of it feels hacky and feels like I’m doubling up on work.

The developer experience is super important. If you can prove to people that the framework can allow them with the least amount of friction to build an app that can adapt to frequent change (e.g. package updates as well as project changes), then I think Ember would look more enticing to developers and therefore potentially be used in more projects. Can’t tell you how many frustrations I’ve had using create-react-app and manually updating Webpack per project, that Ember already solved years ago.

One thing that I found Ember very strong with is that its strong opinions are reflected in the third-party ecosystem: lots of add-on developers build stuff which mimics Ember’s thoughtfully laid out processes (testing & documentation), which means a better dev experience again. Good documentation really is helpful and improves adoption. React and Webpack have really suffered because of that in the past, but they’ve made up for it by meeting other functional needs that people compromise on.

I’ve used Electron with Ember and found it to be very easy to set up. The world is your oyster creating SPAs or even desktop apps with Ember. If there’s anyway to communicate the flexibility and there’s always performance improvements with every release, then I think people could be more curious to try and hopefully delight in the developer experience.

1 Like