Website Redesign RFC

[wifelette]

Rendered.

[heycarsten]

I love it ❤️ I think it might be cool to also add Discourse to the user logos, they’re a pretty big app.

[Turbo87]

Looks great. The only thing I'm missing is not seeing a tomster anywhere on that page 😉

[balinterdi]

I really like it. It emits a professional feel and as much as I love the Tomster (and Zoey) I think their lack makes aligns well with the friendly professional tone. The copy seems to be focused and on point, there's a clear message – Ember is a (the?) all batteries included framework and makes your team very productive.

And of course I'm very happy to see the Rock and Roll book as an official recommendation :)

[samselikoff]

@balinterdi agree that the "Batteries included" is important to convey! Glad it came through.

FWIW the Podcasts/Books/Videos section is something of a placeholder now – not exactly sure what they will say and what will happen when you click them, but we all absolutely think the homepage should make it easy for folks to find community resources. I believe @jenweber has some ideas here.

[heycarsten]

[redacted] you are heard, I think it is important that we try hard to be kind to each other and trust that we all want the same outcome: a great website for Ember.

Your suggestion that the homepage should be communicating some sort of one-upmanship is probably not going to fly very well around here, we’ve been there, it doesn’t work, creating conflict isn’t solving any problems in the world.

The chosen direction seems refreshing to me as well as others. We are all ears, but we need to be respectful with the language we use, and we need to be honest and open with each other. If you disagree with my observation here, please let's talk about it. Judgement free zone.

[samselikoff]

To be a little more specific, the "Batteries are included" section is meant to be the primary way we communicate our differentiated features. The Ember community is also known as being friendly, which we try to show specifically in the Community section as well as generally throughout the design.

We'd love to hear specific examples where you believe the current design doesn't communicate Ember's unique position, or suggestions on what's missing to help it do a better job of that – but let's stay away from ad hominem comments like "it was done with a text editor." They're not helpful.

[mikkopaderes]

I've suggested this before in Discord. I believe having the latest LTS and current versions would be very helpful. Navigating to see the LTS is a pain. You have to go to Releases > Channels and scroll down and read a lot of stuff to see it. But I think most of the people (especially newcomers) would go to Releases > -- Stable.

See nodejs.org for inspirations.

I'm thinking that the latest Ember CLI should be the one that we show in the front page as its version only gets bumped up when Ember and Ember Data bumps up their versions too (AFAIK).

EDIT:

Also, I think Tomster could be a semi-transparent backdrop from the dark hero section. I think it could give a sense of professionalism and some of traditions/culture at the same time.

[josemarluedke]

🎉

Love it! ❤️ The design really represents well the message of "friendly professional" and not showing tomster or zoe really enforces that.

Specifying exactly what the content will look like, will be important to represent the state of ember and what we want people to recognize ember for. But I also agree that is somewhat implementation detail.

I really appreciate the openness of this process and that the community will be welcome to contribute building the website.

However, I believe we as a community will need a good amount of guidance to implement well these design pieces. It would be interesting to have a guide for how to go about implementing these design elements such that puts us in a good place for maintenance of the code as well using modern HTML & CSS techniques. This guide should be laying out the architecture of how the css + html + components of this page will be implemented. eg. how to efficiently build the background elements.

Another consideration is mobile design. I believe the website should be responsive and work very well in mobile devices. This is important to give a good experience for folks coming from their phone. Maybe are coming into the website while listening to a podcast or just surfing the internet while commuting.

I'm super stoked to see this work happening and I'm looking forward to help building it. ❤️ 🎉 ❤️

[samselikoff]

@josemarluedke great feedback! We are going to tell the designer to work on some mobile screens once we reach a strong consensus on the current overall aesthetic.

Rest assured the site will be 100% responsive & mobile-friendly.

[betocantu93]

This is great.

The older site also makes it difficult for our current users to promote their technology choice, and to get their team members on board

This is super important, and in that sense maybe adding the Codesandbox link with an ember sandbox with the stable version could help? I mostly use golang for all my backend services, and I love the go playground, it's literally the first thing you see at their homepage.

Or even using any embeded live editor like the React website, I think GraphQL had this live editor thing too and it was super cool.

Edit:
My bad, I didn't notice the Editor thing already planned in the design. Looking forward to see it 🎉

[jkeen]

I absolutely love this! It looks friendly and professional and clearly outlines what makes Ember great—"Batteries Included" is phenomenal. A huuuuugggge improvement! Can't wait to see this come to fruition. Great job all involved!

[webark]

Think it looks great! Thanks for this.

One thing is the center aligned body copy. Center aligned body copy drops readability way down, and can be very distracting when you are a consumer of the information rather then the look or design of it. Especially in copy heavier sections like “batteries included”.

[jgwhite]

This is sensational. The new copy matched with the new aesthetic is so confident (without being arrogant or throwing shade) and does an incredible job at crystallising what sets Ember apart. 👏

[tim-evans]

This looks very pretty! My first thought is some of the color choices don't have enough contrast for users that need higher contrast. I put the colors into here that shows the color contrast as defined by the WCAG and saw that a bunch of the color choices are failing for small text. Hope this helps!

[jenweber]

I feel that this design achieves being both inviting to new learners and professional in a way that will appeal to companies. That’s tough line to walk! Cheers to the designer for capturing that.

I think the learning team and friends can help fill in some of the implementation strategy. We have ember-styleguide powering most of the styles on our public sites now, which will make this transition manageable. I think this design seems portable and extensible to other pages, something I was super worried about until I saw the mock-up. I will try to add some comments towards “how do we implement this.”

[simonihmig]

Having voiced some criticism about Ember's marketing before, I am really happy where this is going! 😍

I feel that this design achieves being both inviting to new learners and professional in a way that will appeal to companies. That’s tough line to walk! Cheers to the designer for capturing that.

Agree! Good balance of gray/black tones vs. color and content density / use of white space.

Some of the secondary goals include reorganizing information on internal pages for generally better information architecture

While I have nothing to complain about regarding the visual design, I still see a lot of room for improvement regarding content and IA. The content for the homepage looks very good so far, but the RFC does not lay out any plans to further reorganize the IA, except for the vague sentence above.

So is there any?

If so, it would be nice to share some details, even in some rough form like a sitemap. If not, as I said before, I see room for improvement. I could try to write down some thoughts and ideas after the holidays, if this seems helpful!?

Thanks again for all involved here 👏, and Happy Xmas everybody! 🤶🎅

[cibernox]

Maybe some of these ideas are already planned for inside the "Build Pipeline / Routing / Data Layer / Acceptance Testing / Performance / Easy upgrades" tabs, but on the image we cannot assess the content.

---

I like the design but I feel we could use a little more of "Why choose Ember?" when compared to Angular, Vue and React.

At the end this landing page and its content will be one important driving force (perhaps the main?) to encourage people to try Ember (Emphasis on try).

As I see it, most people who dismisses Ember hasn't really given it a chance. As I see it, trying it is loving it, so the most effort we put in pushing people to dip their toes in it the better, even if that means mentioning the competence.

It doesn't need to come up as "trashing other frameworks" if done well, but a highlight of the differences that make Ember more productive.

May I suggest that the batteries included could have some kind of illustration like slider like:

Build your                                                               Batteries-included
own framework                                                                productivity
    <-------------------------------------------------------------------------------->
React                        Vue                    Angular                    Ember 🔥

I'd also mention somewhere how Ember.js is blazing fast because of the VM-based approach. This kind of technicalities may seem vane, and I don't advocate for it to dominate the tone of the landing page, but we all know these "speed" arguments resonate a lot with the programmer mindset. I'd give the crowd what they want to hear.

In the Acceptance testing I'd emphasize the fact that we test on real browsers (and perhaps about the parallel testing in multiple browsers with ember-exam?)

[snewcomer]

I second @cibernox well-put thoughts; however, I don't think the "slider" would be prescriptive enough. I remember back when I was interviewing, there were several companies (energy and the like) interviewing candidates to ALSO help make the decision on "why" this framework over that. They narrowed it down to "Ember" or "Angular" based on high level ramblings but were still at the stage of a project deciding which to choose and the candidates helped them flush out available expertise, advantages, disadvantages, state of the community etc.

Decision Tree

One could imagine (although not a small effort), a section that walks users through that decision process similar to the recent npm 2018 survey. So first question would be "What are you looking for in a framework?" with options like stability, community size, rendering performance, etc. From there, many paths could be taken. At each step, we would describe why Ember would/would not be good for a given path. So if they are at a decision node where the user selected "Performance", we lay out an honest comparison to other frameworks, describe why Ember may or may not be good for certain applications (❌chat widget ✅small to enterprise size app). If they are at decision node about "Community Size", we detail our growing community/npm packages although we have not grabbed the mindshare of communities like React. So honest and truthful, but highlight the positives.

I could imagine such a decision tree to be positive and kind to other communities, while being innovative enough (not aware of such a tool) to be helpful to the thousands of ppl deciding what framework to use on their next project.

Without an improved "Why choose Ember", I still think the redesigned homepage accomplishes a lot (kudos to everybody involved!). I just wanted to present the idea above in case it seemed compelling enough or other ideas branched off of it.

[Gaurav0]

Why is "A Simple Component" section shown 3 times?

[simonihmig]

Why is "A Simple Component" section shown 3 times?

Most certainly just a placeholder for final content I think!

[MelSumner]

@snewcomer this sounds like a neat idea for a separate website that is unaffiliated with a specific framework 👍

[MelSumner]

@simonihmig we're handing the IA separately. We have started consolidating this information here: https://github.com/ember-learn/handbook/blob/master/website_sitemap.md

[MelSumner]

@webark we are planning a "why Ember" addition to the information available on the website, although we've needed more hands/time to help write the prose. The idea is that we could provide materials for companies to use when making technology choices. I'm thinking about things like:

1. a one-page sheet (could be printed out and circulated at a corp) about the benefits of using Ember
2. sample job listings (to help combat the "but it's too hard to find Ember devs" strawman argument)
3. a showcase of products that use Ember (and how they use it)
4. whitepapers maybe?

There are more ideas to explore here, although they are not planned for the home page. If anyone is interested in pitching in on this, please do reach out to me on Discord or come to any of the Learning Team meetings on Thursdays (check the dev-ember-learning channel for more info).

[webark]

@MelSumner No, I'm more talking about something like what you said

developers who are thinking about using Ember. It's for C-Suite execs who have heard about Ember and need to know if Ember is the right choice for their next billion dollar multi-year project.

Having come from a marketing background, if you don't have a clearly defined target audience/market that you are trying to reach, things can get fractured quickly. It also is useful for deciding priority and removes a lot of bike-shedding over ideas.

For instance you mentioned "developers who are thinking about using Ember." and "C-Suite execs who have heard about Ember". The the main "call to action" from the homepage is the "quickstart" link. This however doesn't speak to "C-Suite execs" and probably won't speak to the advantages over other frameworks that questioning developers are looking for. However, the section right under that does, so maybe bringing that "above the fold" will cater to one of those markets. Or the "batteries included" speaks directly to those "choosy developers".

A great example of this I feel is the Docker homepage. Their main title is "Future proof your Windows apps and drive continuous innovation", and their call to action is "Migrating Legacy Windows Server Apps". Now docker isn't just for windows users, the majority of their users probably aren't windows servers, but they have seemed to define a very high value target audience of windows users managing old legacy stacks who might not have realized how docker can help them, and are targeting them very directly.

[Gaurav0]

For instance you mentioned "developers who are thinking about using Ember." and "C-Suite execs who have heard about Ember". The the main "call to action" from the homepage is the "quickstart" link. This however doesn't speak to "C-Suite execs" and probably won't speak to the advantages over other frameworks that questioning developers are looking for. However, the section right under that does, so maybe bringing that "above the fold" will cater to one of those markets. Or the "batteries included" speaks directly to those "choosy developers".

The main call to action for "developers who are thinking about using Ember" is the quickstart guide. The main call to action for C-Suite Execs is probably a "Why Ember" page, should that ever get off the ground.

[SolPier]

Indeed, these are great definitions to keep in mind when building the content for these pages.
One page (or one section ?) = one target audience ?

[webark]

The main call to action for "developers who are thinking about using Ember" is the quickstart guide.

@Gaurav0 I would disagree. I think if you are looking into a new framework, you want to see what it will give you, not the most basic experience of startups. You have to click a link, and read or scroll for a while before you get to anything that is a selling point of ember, and even those are cloaked in “quickstart language” and not pulled out and highlighted specifically. I think by pulling the ecosystem or the batteries included sections (and rewording them just a bit) you can get both those audiences.

The ecosystem, you are talking about standards and shared solutions, which if some of the wording is tweaked can speak directly to a “c-execs” bottom line. You can also highlight some high profile partners there too.

The batteries included, you are also speaking to “you don’t have to spend as much time and can get things done quicker with more quality” which speaks directly to c levels desires for using less resources and not redoing things that have already been solved, and developers who want to build software rather then configure frameworks and write boiler plate.

[sheriffderek]

Stealing this from @MelSumner - right off the bat "(Please insert friendly prose and emoji if my words feel too harsh, I'm not angry or anything like that, it's just the internet.)"

Sorry this comment is so long. I've been thinking about this for years.

RE: Look and feel
I love the friendly nature that Ember has put out in the world - but I also see how we'd benefit to giving a fresh surface to things. From my experience - people think that Ember is that old framework from before Angular / with the script tags - and the mascot is part of how they visually connect that feeling. I'm sure the animals will thrive among our community if we can just take them off the main stage for now.

When I think about visual design patterns - I like to know that things can be reusable - and that they can morph as things change over time.

I think that this 'thin line' you are using will offer a lot of versatility. The layered/flat + 3D look of the component architecture could go a long way - and be a language that would lend itself well to explaining the concepts as well as extend to meetup fliers and everything else. I think that's a solid visual angle to take. It seems like it would work great for animation examples and diagrams. Is it 1px?

The type hierarchy is nice and simple. The content is clear / while the skewed isomorphic background references give it some space and keep things interesting. The light and dark areas make me feel like I'm kinda in my editor but not in the terminal. Ember isn't 'a website' or a visual style / - so, I think it's nice how it still reminds you that it's about the code you'll be writing. The only thing I kinda got snagged on visually - was that some of the corners seemed almost too round (or otherwise just inconsistent) - and that kinda fought the tighter ones - which I felt were lending to the 'precision' feel.

While I really have enjoyed the Ember visual style all along / I think that it's a solid move to simplify the color scheme and have this be more about information and less about feel at this time. Fewer colors are making me feel more open-minded. I don't feel like I'm as bound to this aesthetic. It's comparable in tone to our contemporaries - and I think it's smart to allow people to feel neutral when choosing their tools. In some ways, I'd bet that the hamsters warded off some hamster haters (hence my offensive pink insignia to ward off bad clients) haha -- but I wouldn't want to ever think someone didn't give Ember a try because it "didn't seem like their style." This mockup feels sophisticated and to the point. Great job. : )

RE: "Batteries included" - I love the sentiment of this. I found Ember in my ongoing search for a solid SDK for the web. Before that, I primarily used brunch to build. While recently working with some other JS frameworks - and different build tool setups, I can't say that I've found anything that has made me fill with joy the way Ember's CLI does.

That being said, I think that it's really important to go all the way - and really make this clear. A snappy sentence is a great lead-in / but in a sea of buzzwordy 'tech' websites/everything just seems like fluff. What do we really mean? Why use Ember? Why use any framework at all? Who is the audience? What does Ember help you with? So many questions! I often look over the website and try and figure out what Ember is - as if I were new to programming - and I just can't tell what it is.

These days, you don't get to go through all the steps of learning HTML and then some CSS and some JS or RUBY - and level up your knowledge in some reasonable order. People are jumping into MVCish frameworks without knowing how to write markup or how the box model works. I knew a lot about building for the web before I started using Ember and it was still a huge challenge for me. I know from my experience teaching - that there are a great number of people starting their journey into this field with JSX style frameworks. They get up and going - and then anything that goes wrong is a total mystery. Of course, everyone is different - but I've seen many people struggle for years trying to learn from the inside out. The allure of instant gratification is difficult to avoid. I don't think we're going to change that desire - but I think that we could tell a very clear and compelling story about why people came together and put these ideas to work in the first place.

Right now, we aren't competing with frameworks as much as we are competing with mindset. Who can explain the value of their system the most clearly - and who has the best value? I know why I'm so aligned with Ember - but it took me 6 years to run into each of the things that Ember helps me solve - to understand it's value. The average person who is looking for solutions - isn't always going to know what they want yet. But we have a pretty good idea of what those things are going to be / and we can help them see that narrative. I'm just going to say it (because I love you - and you can handle it) - but, "Ember Octane, focused on performance and productivity." - is a great example of a snappy teaser / that has no meaning. I'm unaware of any software design decision that didn't prize those two things. If that is how we're going to bill it - then it needs to have a context. I don't think a comparison chart would be necessary - but the story of Ember is really important.

I'm trying to be quick here... but - Here are some things I like to do: I like to iterate over lists and show the data. Almost all new programmers are going to relate to that. They've probably recently written some for loops and created some objects and added text to some nodes. But soon enough, I want to click on those things. I want to maintain state. I want to remove things - and know their index. I want that list to load some other UI. I want to get some data from another API. I want to play a song - and then go look at a picture of the band on a different page without the whole DOM refreshing and without my song stopping. I want my code to be really tidy and easy to find. I want to have hooks for route transitions so that I can make cool animations. There are tons of things that I've built over and over again trying to get a system that has all of the things I use in every project. The reasons Ember has taken all of these things that we all need - and built out solid solutions for them - is because we need a shared vocabulary. There are at any given time / a best way to do things. We need to have these things / and it's not because it's cool or hip - it's because it's part of a bigger story. Where we have sandbox examples of code - we could pick a few things to compare to JS / a for loop - and templating... written in JS and Ember. Show the WHY. Maybe stagger the intensity and then also show a really complex edge of what Ember can do for the pros.

If you love Ember / you aren't going to be won over by a visual facelift - and if you're a new programmer - might just pick whatever framework uses your favorite color for their UI / or based on their association, but where we can plant our flag is in telling the story of WHY Ember exists. Why it was created / how it has changed - how that timeline works / how we borg the best things from everything around us - and how we're working to craft the most thoughtful tools and design patterns we can - based on an insane amount of knowledge and experience. I don't think a snappy headline can do that all by it's self.

RE: Marketing: @simonihmig - I just read your post - and I agree with a lot of that. I've squeaked my wheels a few times around here / but also haven't put in the time to help. I'm stubborn about my CSS - so, I can't help with that - but I'd put in a bunch of time with being a guinea pig for the learning team / or with marketing ideas / or supplying music / or planning / or anything else - if it's helpful.

I'm not so sure I agree with your order of priorities on all accounts / but for sure new people need to be who we are targeting. I don't think a visual style-guide is paramount - but maybe a general 'feel' guideline. It's all the little choices like the music before conference videos and screencasts / all the tiny things that can make Ember seem a little hokey sometimes. (that's right Jeffrey) hehe. PS: no idea what IA is. (not good marketing of whatever that is - hahaha)

I think a few solid video type things could go a long way. An animated exploration of how the system works together would deliver so much more information in 60 seconds than any website could. I wouldn't want to pander to an attention defecit culture... but that's how you get information to people now. "Learn everything about Ember - in 2 minutes" (I'd click that)

RE: "mention ... VM-based approach" @cibernox - I totally agree. We don't need to talk about what is better or worse - but it's totally normal to say what we have - and how things are different. If 'reactive' programming is what people want - and they are using react... then we are just letting buzzwords rule the day - and most people don't even know what reactive means. We can explain what Ember is and why it works / for which use cases - in a digestible way that is fair and kind.

RE: Why choose Ember - interactive helper @snewcomer - this is a wonderful idea. In my work, I have had a lot of success with interactive story-telling. This is one of those cases where if you offer the user a chance to see all the options / you can build a real trust. We all know that sometimes you might just be better off working with [insert tiny progressive js thing here] in a legacy PHP project... and that's just fine. We're honest. (It might be even better if you go learn a smaller framework before you come back and use Ember for an appropriate project) We don't want people using it for the wrong things and then being frustrated and trashing it for the wrong reasons.

REGARDING BACKENDS: @sheriffderek - Ember isn't really everything you need... maybe to build the UI / but I think it's a huge selling point that you can use any backend - and we can showcase that. Maybe even a diagram. Showing rails / or phoenix / or whatever icons connecting to Ember - or even other frontends iOS etc / all in concert. thing that people already like - will help soften things up.

RE: LTS and 'download' @mikkopaderes @tomdale

This screen always felt strange and kinda disconnected - and not really inviting - as the first thing I see. Can't we just (As 'in the know' ember people - install the LTS with the CLI - or something clever?)

RE: content strategy @webark - As happy as I am with these first visual treatments / I think it would be really beneficial to outline a content strategy first. Even just a simple goal structure. I also strongly believe in using the constraints of small-screen visual design to help in that process. Who is the target audience? What is the overall goal? (I know it seems obvious... but I've never written out an entire set of goals not to learn something I hadn't thought of) If you have 10 seconds and 320x320px of space ... What is the goal? What do you want the visitor to take away? What do you want them to feel? You might see that page 20 times before you scroll down and take more of a chance. In my strategy (when I'm allowed the time) - I have goals for every page and every module. If I can't get those goals outlined / and I can't test with real users - I would have no way of knowing if my design was successful. I'd be more than willing lend my time to any part of that. We are way too close to the project to see how our candor and copy is going to come off.

RE: benefit list @lifeart - I think some of those are great / and could be involved further down the information pipeline - but also / I'm not sure that they will make sense for the surface. Ember (as nice as I know people are) - isn't actually seen as that 'nice' of a community to new people. It can seem downright barbaric. "NEVER USE CONTROLLERS... wait / but actually we all do..." As kind and nerdy as most people here are - we've accidentally created a weird Clique of inside knowlege/"why would you do that" answers - and it comes off as rude and snarky to even the thickest skinned. We aren't the target audience anymore. People waited for 'routable components' for years / and 'tried glimmerjs' - and really / we should just stick to the basic selling points. No one wants to know what that stuff is. No one wants a route that's lazy / or a stuck-up build - and they don't know what JSON API is - and if they do, it's because that one German Ember developer refused to work with them unless we built that type of API. I think that explaining what RFCs are - and many of those things on the list are really huge benefits / but maybe a layer deeper. We have to get people excited - or interested... and then kinda roll each idea out in order. (maybe even a learn Ember timed email - for new users. I'd like that.)

REGARDING FLARE @lifeart @sheriffderek - Couldn't we have something on the homepage that shows each 'thing' in a fancy way? "SSR support": (button - reveals a bit of server rendered code / suggests you look at the source), "Route transition hooks for animation and data bla bla": (click link that grabs all this data and does some rad animation) --- I like the simplicity of the type in the mockups - but I'm also thinking there are opertunities to show what Ember can do. "Crazy fast rendering" (click button - render 200 animations / think @ef4 - and just reorganize the entire page or something wild... ) - It would certainly need to be tasteful - but just because we are 'nice' - doesn't mean we shouldn't show off.

RE: explaining WHAT ember is + addons @crhayes - I also like where it's going / but I want more. What is the 'eco-system' - and why is each part chosen? What are their values? Can I feel safe, please? As far as Addons - they have always felt confusing to me (especially file-structure) --- but surely pointing out 3 solid add-ons / 'moment' or something for time or numbers / and maybe a carousel slider or something - and maybe a build tool type one / to show how much area they cover. That's should make its point clear to a majority of people who have likely used jQuery plugins or Framework wrapped JS components like a date-picker. I know it's political in a way / but having the plugin observer API to search right there would be cool.

RE: Chris should weigh in: @mansona - Totally agree.

RE: batteries - tab content: @samselikoff - ah ha.. this is more detailed. - but / what's 'routing'? Are you sure I've used MVC frameworks and that I come from a Rails background? I know we can't explain how JavaScript works... and there has to be a level of entry - (which I've never really seen outlined anywhere) - but "Acceptance testing" - might not mean anything to people. I'm not even sure what the tests are called anymore. And I don't want to have a bunch of baby talk - but as an example "Get full test coverage of your entire application - from each component - to full user interaction stories - with a delightfully elegant syntax" - might be more meaningful to our target audience.

~ side note... and a pain point for beginners / the batteries are included - but there certainly isn't a server or a database included to populate that first controller data property. Mirage could be helpful in making it feel fully functional.

RE: what is the homepage for @MelSumner - I really like how you're outlining some goals here - and I think that they are key to determining if a design is successful.

4 hours later... I've read all the things! Yikes. Keep up the good work! Let me know if I can be of any help. I know there are a lot of cooks in the kitchen / but it's part of my job to be able to temporarily forget everything about a subject - and see it with fresh eyes. As someone who has been learning - and is still constantly trying to learn more about Ember - I still know how it feels to be totally overwhelmed - and how when you "Learn Ember" - you are learning a whole lot more than that - all at the same time.

PS: Are we brave enough to skip dropdowns and count on landing pages for each area to guide the user - and tell that story?

PSS: The redacted or removed comments on this RFC are a bummer. I would have liked to have read them / or not read the references to them - out of context.

[mansona]

Ok wow 😳 what a comment @sheriffderek 🎉

It took me a while to get through but I'm really glad that you took the time to work on this. I think you've captured quite a few nuggets that should be remembered (and I will no doubt be coming back to your comment for reference).

A few things jumped out to me on first reading:

but where we can plant our flag is in telling the story of WHY Ember exists. Why it was created / how it has changed - how that timeline works / how we borg the best things from everything around us

I have always thought we need to tell a better story about our history. There is a lot of things that we are doing now that are as a result of our history and even the fact that we care so much about backwards compatibility is baked into that story.

I think you also hit on a good point here:

I think that explaining what RFCs are - and many of those things on the list are really huge benefits / but maybe a layer deeper.

While I agree that we should probably highlight the RFCs: I think the idea of considering this as a set of layers is very important 👍 I mentioned in my comment that we should probably be thinking about what we want to see on the Homepage and not really considering "all the possible content that could be anywhere on the website", and your idea of using "layers" really helps here. I recently created an issue to create a "Why Ember" page and we can consider it like this: We need a headline that grabs people's attention on the topic of "Why Ember" and then have a "Read more" link that navigates to a page that has further discussion on the topic, and has the space to go into some of the more nuanced discussion. You said it quite well when you said:

We have to get people excited - or interested... and then kinda roll each idea out in order.

🎉

[mansona]

Now to address some of your more functional points 😂

Let me know if I can be of any help

Apart from the help that you've already been giving by spending so much time going through all the comments and giving your insights you mean!? I jest, but I guess it is important for everyone to remember that these RFCs only represent the tip of the iceberg when it comes to getting things done. We would very much appreciate your help on this whole topic when the RFC is merged 👍 You can get involved by hanging out in #st-website or #dev-ember-learning in the Ember Community Discord. You are no doubt aware of these channels but I'm phrasing it like this in case anyone else comes across this RFC and may want to get involved 🎉

PS: Are we brave enough to skip dropdowns and count on landing pages for each area to guide the user - and tell that story?

What do you mean by ☝️ exactly? Are you suggesting that we have multiple landing pages? Related to my point on the "Why Ember" page, this is not beyond the realm of possiblities 👍 We can chat about that once the RFC gets merged

PSS: The redacted or removed comments on this RFC are a bummer. I would have liked to have read them / or not read the references to them - out of context.

I would imagine that the removed or redacted comments are mostly likely beause of community guidelines violations so I wouldn't worry about them 😄

[heycarsten]

PSS: The redacted or removed comments on this RFC are a bummer. I would have liked to have read them / or not read the references to them - out of context.

@mansona @sheriffderek If you're referring to my comment that begins with [redacted] you can just click "edited" and see the user I was replying to. Sorta gapped on that! They actually deleted their own comment. The gist of it was basically "we need to be aggressive and show how Ember is better than everything else". I suggested that we have done that in the past (so has pretty much everyone else) and it really doesn't work. It just inflames people and insights unproductive banter. I feel it's better to focus on what Ember does well and why vs. how Ember is better than x, y, z. That's the direction all this is going anyways.

✌️

[Dave-Choi]

A misconception that I see a lot on reddit is that Ember is like hopelessly intertwined, rather than curated, but modular with escape hatches. People tend to be surprised that you can use Ember with parts swapped out, like https://github.com/bgentry/ember-apollo-client

I think if that were more clear, people would be more open to trying it out, even if they have a strong attachment to some specific part of their stack, or if they heard something bad about ember-data once.

[wifelette]

Really grateful for everyone taking so much time to give thoughtful feedback! We're making great progress here!

I'm staying out of the weeds since there are other experts around here digging in more helpfully than I could, but I wanted to address one point: The Tomster imagery. This has been an ongoing topic of conversation on the crew most involved in getting this new design sorted, and we're working towards next iterations. (cc @Turbo87, @mikkopaderes and others who commented on this bit).

We got a lot of good feedback on and offline about this design successfully "maturing things up," and a lot of that was by nixing the illustrations. But the longtail of the feedback has many feeling like we shouldn't go cold-turkey, both since it's a real current part of our identity, and because we don't want to completely eliminate the past stuff.

Other feelings from the core team feedback longtail were that the site, while beautiful, lacks a bit of... memorable-ness :p Not a word. Again though, the thought is that integrating some illustrations back in in some clever/homage-based/creative way could kill both birds with one stone.

We're steering clear of specific instructions to the designer like "put a tomster here" because as I'm sure you know, results tend to be better when you give the professional (designer) your intentions, not specific instructions, so they can run with it creatively and really integrate the intent into their solution(s).

So TL;DR the next iteration is in the works, and this is one central point it will involve thinking about. I'm feeling really good about this whole thing and hoping we can move to FCP after one more iteration on the comp.

[james-mcdon]

Hey folks,

I'm James. I helped come up with the visual design for the new approach for Ember. I've enjoyed reading some of your comments and feedback - really appreciate everyone who has taken the time out to have their say. I'm working on an iteration where we can embed the "friendliness" aspect of the original Ember website into this new design. You'll all hopefully be able to see it soon.

Thank you,
James

[wifelette]

Another update just to tell folks that this hasn't gone stale :) We're hoping to have more to add within the next 2-3 weeks. We're looping in Lindsey, original Tomster designer, too, which will help us stay true to the original Tomster brand but also will take more time since... more humans :p More to follow!

[MelSumner]

We have decided to move this RFC into FCP- while we agree that there will still be some details to work out, we feel that there is enough consensus on the overall direction to move forward.

[chancancode]

The framework core team discussed this on today's meeting and we are in favor of accepting this RFC. However, this RFC is ultimately co-owned by the steering committee and learning team so we will defer to them to have the final say.

[mansona]

I'm very much in favour of this merging so we can get started on building the new design 👍 As I mentioned before I believe this is a living document and once (if) this does get merged we will we working together with the community to build a design language based on what has been agreed in this RFC, that we can then adapted for all of the web properties that the various Ember teams support. I look forward to getting started 🎉

[rwjblue]

This has been in FCP for a while now, no new comments/suggestions have come in for a few weeks, so it is now time to land 😄.

Thank you to everyone who helped out on this, your feedback absolutely has helped ensure that we have a much better end product. 👏 🎉

[sheriffderek]

I just saw this link in an old embermap email: https://sketch.cloud/s/1OAxa/kRekA9 - and it basically goes through that whole process I was ranting about.

[frank06]

"A framework for ambitious web developers." I think there is no need to put that. Ambitious doesn't differentiate Ember in any meaningful way.