Rethinking the Phoenix landing page

[paulcsmith]

As discussed in IRC, the current website aesthetic is fairly generic and focuses a lot on technologies and not "human" reasons to switch. Compare the phoenix homepage to Ruby on Rails or meteor which focus less on technologies and more on what the framework has to offer developers. "Build apps that are a delight to use, faster than you ever thought possible" (Meteor), "Web development that doesn’t hurt - optimized for programmer happiness and sustainable productivity" (Rails), compared to "A highly connected web framework" (Phoenix)

Goals for the redesign:

• More powerful branding. The current website blends in and doesn't have much emotion. I went with the Phoenix orange to make a more powerful impression.
• Emphasize the reasons for using Phoenix, not the technologies.
• Make it clear how to get to the guides
• Make it clear where people can go to get excited and see how an app is built.

My questions for everyone are:

• What made you switch to Phoenix?
• What did you switch from?
• Why did you switch?
• What led you to try Phoenix?

Note: when I say "switch" that doesn't mean you use it exclusively. It just means you used to use one thing for a given problem and now you use Phoenix in that scenario.

For me, it was the speed and syntax of Elixir and Phoenix. Tests suites ran fast, dependencies installed quickly and the framework itself was ridiculously fast. That wouldn't have been enough though. It also need to have a beautiful syntax and nice APIs. This is the only framework/language combo I've found that covers all those things. So that's what I emphasized in the mockup. I wanted to make it clear that you get blazing fast speed without sacrificing a happy dev environment.

Let me know what you think! Feel free to leave comments. This is very much a WIP. The real version would have real numbers and maybe even a chat with benchmarks along with some example code. I strongly believe that the screencast should also show some benchmarks at the end to make it clear that you're writing beautiful code and getting speed at the same time.

P.S. The content below the blog line is very much a WIP. I'm mostly focus on the header section right now.

[lancehalvorsen]

:+1: for upping our marketing game. Lot's of great ideas/insights here.

More later . . .

[kgish]

Hi there.

I think that the reasons mentioned cover pretty much how I feel, so in that regard I do not have that much to add really.

Speed and scalability are prerequisites nowadays for any kind of framework anyway, so if you intend on differentiating yourself from other frameworks it's probably best to avoid these buzzwords.

Maybe I'm a bit old-fashioned but I tend not to take hype very seriously and prefer to focus on professional aspects. Like tooling, documentation, deployment. More example projects would be nice for illustrative purposes rather than code snippets alone.

The website is very sound and in my opinion an excellent site with loads of valuable information, especially the API reference. Try and keep this basis of the website intact and build upon it. Avoid fancy-sounding terms and hype. I like the fun-factor as it attracts visitors.

You cannot write fast web application with the backend alone, so giving the impression that just using the phoenix framework will solve your problems is not correct. A REST based javascript mvc like ember.js is recommended, so stress how easy it is to integrate these kind of spa's with such a back-end and you've got a winning combination that's for sure.

If you still insist on including 'blazing fast' maybe change it to 'blazingly fast' instead. Blazing already infers that it's fast, so perhaps something like 'blazingly fun' or whatever would sound better.

Regards, Kiffin

Kiffin Gish Gouda, The Netherlands

On 03/13/2015 06:09 PM, Paul Smith wrote:

As discussed in IRC, the current website aesthetic is fairly generic and focuses a lot on technologies and not "human" reasons to switch. Compare the phoenix homepage http://www.phoenixframework.org to Ruby on Rails http://rubyonrails.org or meteor https://www.meteor.com which focus less on technologies and more on what the framework has to offer developers. "Build apps that are a delight to use, faster than you ever thought possible" (Meteor), "Web development that doesn’t hurt - optimized for programmer happiness and sustainable productivity" (Rails), compared to "A highly connected web framework" (Phoenix)

Goals for the redesign:

• More powerful branding. The current website blends in and doesn't have much emotion. I went with the Phoenix orange to make a more powerful impression.
• Emphasize the reasons for using Phoenix, not the technologies.
• Make it clear how to get to the guides
• Make it clear where people can go to get excited and see how an app is built.

My questions for everyone are:

• What made you switch to Phoenix?
• What did you switch from?
• Why did you switch?
• What led you to try Phoenix?

/Note:/ when I say "switch" that doesn't mean you use it exclusively. It just means you used to use one thing for a given problem and now you use Phoenix in that scenario.

For me, it was the speed of Elixir and Phoenix. Tests suites ran fast, dependencies installed quickly and the framework itself was ridiculously fast. That wouldn't have been enough though. It also need to have a beautiful syntax and nice APIs. This is the only framework I've found that covers all those things. So that's what I emphasized in the mockup. I wanted to make it clear that you get blazing fast speed without sacrificing a happy dev environment.

Let me know what you think! Feel free to leave comments. This is very much a WIP. The real version would have real numbers and maybe even a chat with benchmarks along with some example code. I strongly believe that the screencast should also show some benchmarks at the end to make it clear that you're writing beautiful code /and/ getting speed at the same time.

phoenix v1 https://cloud.githubusercontent.com/assets/22394/6643304/a8305a46-c981-11e4-9614-b9f658278bbf.png

— Reply to this email directly or view it on GitHub https://github.com/lancehalvorsen/phoenix-guides/issues/169.

[chrismccord]

You cannot write fast web application with the backend alone, so giving the impression that just using the phoenix framework will solve your problems is not correct. A REST based javascript mvc like ember.js is recommended, so stress how easy it is to integrate these kind of spa's with such a back-end and you've got a winning combination that's for sure.

Phoenix is great for a backend of any JS framework you choose, but I don't agree with this particular point. If we are to highlight anything along these lines, it would be that Phoenix is great for both HTML apps and REST backends.

@paulcsmith fantastic work. The wording is exactly what I had in mind. I will have more thoughts soon.

[Kosmas]

:+1:

[kgish]

@chrismccord sure, I understand what you're saying. I'm not implying that Phoenix isn't great, it is! What I meant was that I've seen examples in the past where slow clients have given the impression that a given backend was slow and don't think that such a great product like Phoenix deserves a bad rap.

[josevalim]

Thanks @paulcsmith, this looks great! It does provide a much more human approach to the marketing page which is awesome. I believe there are three sides of Phoenix that we need to emphasize:

1. You don't need to choose between a slow application and a productive environment. Phoenix gives you both. This is the message you have nailed!
2. Highly connected, inside-out. This has two sides:
   • Elixir makes it easy to connect your machines and distribute work between them
   • Not only that, Phoenix makes it easy to connect your clients to your web applications, be it your browser or a native application
3. Phoenix applications are easier to maintain. This is hard to prove but we could rely on Elixir for that (as the language descriptions says it is designed for maintainable and scalable applications).
   • Functional programming leads to easier to maintain software because the complex parts of your application are made explicit (e.g. state)
   • Elixir already provides a structure for designing composable applications and Phoenix simply relies on that

We don't need to talk about all of those and they don't need to be given equal importance but those are areas we have to highlight and explore.

That's it. I am not proposing any change in this comment (I will do that in a later one). :) One last thing that we need to be very careful about: we should not position ourselves as a special case. I have already heard some people saying that you need Elixir (or Go or Scala) just when you have a performance issue or you have a special use case. We need to be careful to not validate this idea (and I think you have done a good job in avoiding it too).

[josevalim]

Ok, this comment aims to be more specific in the feedback:

I completely agree with your goals. I personally wouldn't change any of the goals. The only change I would try to make is include "productive" in our main description. Since we already say "development environment" in the tagline, I thought about:

Most languages make you choose between speed and a productive environment. Phoenix and Elixir give you both.

Regarding the "How is Phoenix different?" section, we are mostly arguing about why Phoenix is productive and fast. I though we could break that into two or three different columns, each highlighting the points I have mentioned in the previous comment. The text below are just examples of how we could explore them:

1. How is Phoenix different?

   Phoenix is a productive framework for building any kind of web application, from HTML5 applications to API backends. Phoenix is built on the Elixir language and both were designed with developer happiness in mind. The syntax is beautiful, the tooling works and the runtime is fast.

2. A framework for the new web

   The web today is drastically different from 10 years ago. Phoenix embraces the new web via channels, an abstraction that allows your application to stream and receive data from clients on demand, be it in the browser, a native mobile application or an embedded device.

3. On the shoulder of giants

   Elixir is a functional language that runs on the Erlang VM. You will find functional programming will lead to more maintainable applications, by making the complex parts of your software explicit, while enjoying the guarantees of the Erlang VM for building scalable and fault-tolerant systems.

We could also finish each section with a link:

1. How is Phoenix different? Check out our guides (link to the guides)
2. A framework for the new web: Build an app for the new web (link to the app with 10000 connections)
3. On the shoulder of giants: Learn Elixir (link to Elixir home page)

Thoughts?

[chrismccord]

The only change I would try to make is include "productive" in our main description.

:+1:

I'm 100% on everything @josevalim said. Couldn't have said it better myself. I think the language and flow @paulcsmith has now with @josevalim's feedback will be perfect.

[paulcsmith]

Thanks for all the feedback! I'm glad you like the direction it's going. I'll have an updated version near the end of the week.

[paulcsmith]

I'm going to start the HTML and CSS tomorrow and next week. I checked with Readme.io and they do allow custom CSS, but there is no sandbox or test mode, which will make it extremely hard to test any changes. I'm thinking that I would do the HTML and CSS and we can host it on GitHub or somewhere else, disable the landing page on README.io and point the root to the page on GitHub (or wherever else it's hosted). This will also make it easier for others to contribute to the design and I think will help with editing the content since we can use PRs and see diffs more easily than on Readme.io

So, can we create a repo under the phoenix-framework organization to host the landing page, or would you prefer to do something else? We can always figure out the deployment as we go later since it will take a bit to code and polish the content.

[josevalim]

Maybe it is ok to have the website temporarily "ugly" while we do this? I am not sure how well it will play if we break the website in 2 different places.

José Valimwww.plataformatec.com.br http://www.plataformatec.com.br/Founder and Lead Developer

[chrismccord]

Perhaps you can locally clone the readme assets and add your own customizations to the static site. Then when things look someone ok, we can throw up your custom html/css on the readme admin side? I think a few blips here and there are fine like @josevalim said.

[paulcsmith]

I definitely would prefer to keep it all on Readme.io, but I didn't see a way to do. I would clone the assets locally and then restyle it, but I don't see a way to do that. Is there a git repo on Readme.io with all the HTML? If so I don't see it, and after googling I couldn't find anything. I'll ask their support team, but it doesn't seem likely to me.

Also, if we do go that route (using Readme.io's custom CSS) I still think we should have a repo somewhere for versioning the CSS.

[chrismccord]

I believe a field -> save page as in FF will copy all the assets and rewrite the paths?

On Mar 26, 2015, at 1:46 PM, Paul Smith notifications@github.com wrote:

I definitely would prefer to keep it all on Readme.io, but I didn't see a way to do. I would clone the assets locally and then restyle it, but I don't see a way to do that. Is there a git repo on Readme.io with all the HTML? If so I don't see it, and after googling I couldn't find anything. I'll ask their support team, but it doesn't seem likely to me.

Also, if we do go that route (using Readme.io's custom CSS) I still think we should have a repo somewhere for versioning the CSS.

— Reply to this email directly or view it on GitHub https://github.com/lancehalvorsen/phoenix-guides/issues/169#issuecomment-86641793.

[lancehalvorsen]

@paulcsmith in dash.readme.io for the site, try clicking on dashboard -> appearance -> custom stylesheet.

Also, in a pinch, we could create a "styling" directory in this repo to save custom css.

[paulcsmith]

@lancehalvorsen That sounds good to me. a styling directory would be perfect. I can even include the downloaded HTML/CSS to make it easy for others to contribute.

@chrismccord That worked perfectly. I was way overthinking things. Thanks :)

I still have my doubts about using readme.io since they don't offer a lot of flexibility with the content or the HTML. I'll see what I can do though

[lancehalvorsen]

@paulcsmith perhaps my first answer didn't quite get at your whole question. Sorry if I failed at that. :^)

Currently, with the way readme.io works, our updating process is pretty manual - lot's of copying raw markdown and pasting into the site. I suspect that custom markdown/css is going to be in the same boat.

[lancehalvorsen]

@paulcsmith boom! A new styling directory now available for custom stuff. :)

[chrismccord]

I still have my doubts about using readme.io since they don't offer a lot of flexibility with the content or the HTML. I'll see what I can do though

Yeah the process is a little clumsy, but it lets us focus on bigger things instead of setting up/managing/deploying a middleman/jekyl/etc app, so hopefully this process won't be too frustrating for the homepage. We can re-evalulate readme later, but for now it saves us time so we can ship great content and code :)

[paulcsmith]

@lancehalvorsen Thanks! That's what I'll do for now.

@chrismccord That makes total sense for now. I know you and the core team are working on a lot of things right now, and I'm very grateful.

If we want more customization in the future, I think we could use GitHub pages with a custom domain. That way deployment is as easy as merging to the branch gh-pages. Then the management/setup is not hard. Just clone the repo, make the changes, open a PR and merge it in. The rest of the site can use the Readme.io theme, or a very slightly customized version. The focus of the repo would be on the landing page. For now I think I can make it work with Readme.io :)

[josevalim]

Hello folks, I talked to Bruce Tate about this and he had some great feedback. Here is what we propose followed by the rationale of the change.

Intro

Productive. Robust. Fast.

Most frameworks make you choose between speed and a productive environment. Phoenix and Elixir give you both.

Rationale: More memorable, less repetitive.

Subsections

How is Phoenix different?

Phoenix is a productive framework for building any kind of web application, from HTML5 apps to API backends. Phoenix is built on the Elixir language and both were designed with developer happiness in mind. The syntax is beautiful, the tooling works and the runtime is fast.

Discussion: "How is Phoenix different?" is not necessarily good heading because different doesn't imply better or worse. We haven't come up with something better but it is worth discussing.

A framework for the new web

The web today is quite different from 10 years ago and Phoenix embraces this new web with channels. Channels provide data streaming for building rich and interactive applications, be it in the browser, a native mobile application or even in embedded devices.

Discussion: made it shorter, added focus on what you can build with it (not how)

On the shoulder of giants

Elixir is a functional language that runs on the Erlang VM. You will find functional programming will lead to more maintainable applications, by making the complex parts of your software explicit, while enjoying the guarantees of the Erlang VM for building scalable and fault-tolerant systems.

Discussion: none (yet)

[lancehalvorsen]

Ideas: Instead of "How is Phoenix Different?", what about "What Makes Phoenix Great?" Another thought, "Why Should I Try Phoenix?"

[lancehalvorsen]

An idea for the "A framework for the new web" paragraph:

The web is evolving very fast. Phoenix embraces this change and anticipates the future with a real-time streaming and pubsub technology called "Channels". Channels let us build rich, interactive applications that can communicate with any type of connected device.

[josevalim]

Here are some updates based on @lancehalvorsen feedback and some more I heard today. Some folks said "How is Phoenix different?" is actually a good heading because that would be their follow up question. Everyone loved the "Productive. Reliable. Fast." bit.

Building the new web

The web is evolving very fast. Phoenix embraces these changes with a real-time streaming and pubsub technology called "Channels". Channels let us build rich, interactive applications, be it in the browser, a native mobile app or even in embedded devices.

Discussion: made it shorter, added focus on what you can build with it (not how)

Battle-proven technology

Elixir is a functional language that runs on the Erlang VM. The Erlang VM was designed to handle millions of connections at the same, which Phoenix leverages for real-time streaming, while also enjoying the VM guarantees for building fault-tolerant systems.

Discussion: Battle-proven is clearer, we talk about handling millions of connections too! Less about FP.

[chrismccord]

Discussion: Battle-proven is clearer, we talk about handling millions of connections too! Less about FP.

This is a great change

Discussion: made it shorter, added focus on what you can build with it (not how)

:+1:

These changes are really nice. Short & simple and gets our messaging across.

[chrismccord]

"How is Phoenix different?"

I think this can work, but we could also make it,

"What makes Phoenix great?"

"A framework for the new web"

I think this can work well. We could also do something like this, if we don't mind the metaphor:

"Rising above the status quo"

[lancehalvorsen]

I'm seriously :+1: on these changes.

I would suggest a slight edit to the "Building the New Web" paragraph - from this:

Channels let us build rich, interactive applications, be it in the browser, a native mobile app or even in embedded devices.

To this:

Channels let us build rich, interactive applications in the browser, in native mobile apps, or even in embedded devices.

[josevalim]

Agreed with the latest proposal too!

José Valimwww.plataformatec.com.br http://www.plataformatec.com.br/Founder and Lead Developer

[paulcsmith]

These are some really great ideas. I need to find time to get the design and HTML done so we can play around with the text. I'll have some time to do this while I'm on vacation next week :)

I am not sure of the "Productive. Robust. Fast" headline because I feel that it is memorizable, but not memorable. There is no context yet, so the brain has nothing to connect it with. What is this? What is fast and productive? The missing key is that it doesn't explain what you can do with Phoenix. Productive. Robust. Fast could be applied to a manufacturing company, a football team, etc.

I believe the goals of the intro headline and accompanying paragraph should be:

• Explain what you can build with Phoenix
• Explain what makes it different
• Explain why those differences make it better

The intro paragraph explains the difference (fast, and also fun) and we can assume that people know why fun and fast are good things, but we don't explain what Phoenix is.

My proposal is that we combine the two suggestions somehow.

Some ideas

• Write robust, and blazing fast web applications.
• Create a new breed of web applications. Fast. Robust. Productive.

Thoughts?

[josevalim]

I am not a marketing specialist (the person who suggested it actually was) but isn't memorizable exactly what we should go after?

Take Nike for example: "just do it". It applies to anything, it couldn't be vaguer, but it was actually the first example that came to my mind when writing this, from all existing brands.

So I would say: go with memorizable. If that is the first thing that comes to mind when they think about Phoenix, great! We should explain what Phoenix is about right after (I believe we mention "web framework" in the next sentence, right?).

Finally, I actually realized I didn't remember Rails message (web development that doesn't hurt) until we started this discussion. But somehow everyone remembers Rails is about productivity. That's the word that sticks. If we can help those 3 words stick, even better!

José Valimwww.plataformatec.com.br http://www.plataformatec.com.br/Founder and Lead Developer

[paulcsmith]

Sounds good to me! I'll use that then

[kgish]

While both are valid I prefer blazingly fast to blazing fast, the latter being more common, e.g. blazing speed. In my opinion the use of blazingly would stick out slightly better helping to differentiate phoenix from the others.

[paulcsmith]

I like blazingly fast too, but I think we're replacing that line with "Productive. Reliable. Fast"

Maybe we could do "Blazingly Fast" at the end instead of "Fast"

[kgish]

That would be cool also.

[josevalim]

Then it is worth discussing why are we emphasizing "fast" over the other two words? If I would pick one of the three to emphasize, I think "fast" would actually be my last pick. :)

[paulcsmith]

Good point, Jose. We should definitely figure that out. It's interesting because speed is definitely what led me to use Phoenix. I love Rails and find it to be very productive, but it takes so long to test, it quickly gets bogged down under load and that makes me sad :(. I never had major issues with reliability or productivity.

The problem was everything that was faster than Ruby/Rails also required using languages and frameworks that just weren't as fun and productive. So for me, speed was the big thing, because if all I wanted was productivity, I have that with Rails. I realized afterward that it's also quite reliable and easy to debug, but that wouldn't have been enough for me to try it out.

Why did other people decide to try Phoenix?

[josevalim]

@paulcsmith I assume you only stayed though because you found yourself to be as productive in Phoenix as in Rails. I mean, there are plenty of alternatives right there for a Rails developer, but most people still stick to Rails because they don't feel as productive elsewhere.

So fast was what made you look into Phoenix but is it the reason that made you stay? :)

Fast is always a weird thing to aim for, because you can always be faster elsewhere, if you are willing to give something else up!

[paulcsmith]

@josevalim Yes exactly. That's what I tried to explain, but didn't do a good job :P The speed is what made me want to try it, but yes, I would have left if it was not as productive. In fact, I wouldn't have even tried it if I didn't think it would be as productive.

[mutablestate]

@paulcsmith the honest answer is my Grandmother always said "do what makes you happy" - thanks Gran!

I was happy making websites with Rails until starting to work on larger projects where the ‘Railsy way’ was failing me and IMO complex workarounds were needed.

Phoenix gives me the advantages and simplicity of functional programming with immutable state in a productive web framework and that makes me happy.

[paulcsmith]

@mutablestate Thanks for sharing. That helps a lot in planning out the content of the website!

To keep everyone posted: I've started on on styling the Readme.io pages and it's a bit tricky. The CSS selectors are very specific, which makes them tricky to override. This is adding a bit of time, but I'll have some code/content for everyone to look at in a week or two.

[jeregrine]

Paul let me know if you need any help. I've got a little bit of experience in that CSS.

On Mon, Apr 13, 2015 at 9:49 AM, Paul Smith notifications@github.com wrote:

@mutablestate https://github.com/mutablestate Thanks for sharing. That helps a lot in planning out the content of the website!

To keep everyone posted: I've started on on styling the Readme.io pages and it's a bit tricky. The CSS selectors are very specific, which makes them tricky to override. This is adding a bit of time, but I'll have some code/content for everyone to look at in a week or two.

Reply to this email directly or view it on GitHub https://github.com/lancehalvorsen/phoenix-guides/issues/169#issuecomment-92387183 .

[mutablestate]

@paulcsmith more explicitly regarding the website content ;-) The main reason I came to Phoenix was for simple and productive scalability right out of the box.

Thanks for your work on improving the website rhetoric.

[paulcsmith]

@jeregrine Thanks for the offer! Mostly I've just been super busy. I'll hit you up if I need some help though!

Some feedback from Twitter: https://twitter.com/toomuchpete/status/591235217068847105

Reading up on Elixir & Phoenix b/c of the "Existential Crisis at RailsConf" post. Not really getting why this is supposedly better.

If Phoenix's "thing" is realtime, then I totally get it and the marketing is fine.

The current version seems to be overly focused on real time (as we already talked about). So, we need to be sure to mention that Phoenix can be used for real time, APIs and "regular" HTML web apps. We've discussed this before, but I wanted to add this as further documentation.

What's a good way to describe a "regular" web app (with html pages, not just an API)?

[josevalim]

In the earlier docs I was used to say: from HTML 5 apps and API backends to distributed systems.

So my answer is "html 5 apps".

José Valimwww.plataformatec.com.br http://www.plataformatec.com.br/Founder and Lead Developer

[jeregrine]

What if we did that hot new thing where its like

Use Phoenix to build ____

And then it cycles API, Web, Real Time, Distributed Systems, Synergy etc etc. In the under line.

On Thu, Apr 23, 2015 at 2:42 PM, José Valim notifications@github.com wrote:

In the earlier docs I was used to say: from HTML 5 apps and API backends to distributed systems.

So my answer is "html 5 apps".

José Valimwww.plataformatec.com.br http://www.plataformatec.com.br/Founder and Lead Developer

Reply to this email directly or view it on GitHub https://github.com/lancehalvorsen/phoenix-guides/issues/169#issuecomment-95695873 .

[paulcsmith]

@josevalim I like that. Maybe just "HTML apps", since HTML 5 carries a lot of extra meaning with it? (offline, web workers, local storage etc.)

@jeregrine Cool idea. Not sure if it's possible with readme.io? I'm not sure you can use custom html in the header text. I'll have to look.

Also, could someone post an svg/eps/ai version of the Phoenix logo here so I can make it white :) Right now I'm using a desaturated png. Not quite ideal :)

[paulcsmith]

Since HTML 5 apps is pretty ambiguous, how about "server rendered apps" instead of "HTML 5 apps"?Technically SPAs are still HTML 5 apps, so maybe this makes more sense.

I got this term from: http://blog.skylight.io/a-new-sense-of-purpose-for-rails/

[josevalim]

Server rendered apps are fine. HTML 5 apps is fine too in any interpretation, even if it is JavaScript heavy, we will do a great job as an API and integrating via channels.

So I would stick with HTML 5 exactly because it means more but I am fine with any.

José Valimwww.plataformatec.com.br http://www.plataformatec.com.br/Founder and Lead Developer

[paulcsmith]

Ok cool, I wanted to make the distinction so that we can say things like, "Use Phoenix to build APIs, server rendered apps, etc." Sorry I wasn't clear on that.

[chrismccord]

Jason's idea is really great. As far as naming, I've never been a giant fan of html5, but it's the most obvious/succinct choice here imo. Jason's idea with a tag line that uses html5 could work well