Mithril.js: Mithril redesign

[aardno]

A fork of issue Reasons we use Mithril #1026

Here we can propose our approaches to Mithril's logo, slogan/tagline, or site design (freeware only)

Reason: Mithril's community is lacking. A redesign in parallel to a rewrite can promote growth to the mithril community with a well-defined purpose.

[aardno]

My approach is to show Mithril as a rock-solid foundation to any project, with either a minimalist feel (D3 Stonism) or a louder, explicit feel (Rock it).

Rock it

D3 Stonism

@Morklympious proposed:

Hobbiton Brushhand

Elven Common Speak

Removed taglines, I don't see the need for mithril to re-brand

[ArthurClemens]

The origin of the name has nothing in common with the project itself. Forcing the project into this mold will lead to off the mark USPs and tacky taglines. It will also add to the confusion when sifting through the thousands legitimate Hobbit/LOTR sites.

A branding exercise does not start with the name, but with the unique benefits this library brings.

[aardno]

You can argue the same for React with 'React youtube'. You propose a common risk-factor evaluation, but the end-goal is not to make mithriljs famous. The end-goal is to strengthen the mithriljs community, and a little jazz can do wonders.

I'll agree though I don't like the hobbit/lotr theme, and I don't think we should be focusing on the theme as much as the code, but the community is needed IMO

[v4n]

I think the goal should be a clean & modern design to reflect Mithril. To set the tone of what we can be aiming for here is a _prototype_ (by no means pixel perfect):

Uppercase gives the brand a powerful personality. Even though the codebase itself is small Mithril is powerful.

[isiahmeadows]

@v4n The logo + name there feels a little too "fat", if you know what I mean...The font and "fat" style to it reminds me too much of Immutable.js's logo, which IMHO is awful. It just feels really tacky to me.

[drew111b]

@v4n 's change from italics makes a stronger image, but @isiahmeadows is right that the bolding is too extreme. Somewhere between them would be great imo. The italics don't add to the logo.

[aardno]

@v4n and @drew11b I like your ideas, I took some time trying to steal ideas from Haskell's site.

[sebastiansandqvist]

Some ideas on the visual direction this could go in:

1. New color. Mithril isn't green.
2. A different take on the logo (but the existing one is nice too)

I also think that, similar to the react js site, there should be a lot of interactive code samples on the home page, increasing in complexity as you go on.

Since I came here from react, I was attached to the JSX syntax and have been using the MSX transformer as part of my build process. Having the option to switch to that syntax in the interactive code samples may lead to a better proportion of react developers trying out Mithril. That, combined with the new lifecycle hooks, should make it pretty familiar territory for them. Just an idea.

And while we're changing things, I think a more descriptive slogan than "A JavaScript Framework for Building Brilliant Applications" would be a good thing to have.

I didn't do anything different with the layout--I like how the existing landing page is arranged. But here's my take on a possible look for the new site:

[isiahmeadows]

Seeing these ideas pop up make me really think the logo and branding really just need a complete redo. :smile:

As it stands, for a Web framework, we really should have a modern-looking Web page. Looking worse than even jQuery's not-very-good website sounds like a signal to pitch everything to me. :wink:

[pygy]

I, for one, like @sebastiansandqvist's proposal.

[Bondifrench]

@sebastiansandqvist 's proposal looks best so far, should see if there are other proposals anyway.

[JAForbes]

@sebastiansandqvist is aesthetically pleasing, but is also essentially a splash of paint on the original design - instead of a thorough redesign. The core problem isn't that the existing site isn't aesthetically pleasing to the eye - the problem is it does not communicate why mithril is any better than any other library.

Preferences for JSX, and colors are important information, but they need to be grounded in communication.

We need to dig deeper, which is the reason for #1026. I would have advised against tackling these issues yet. I think it is too early. But please, if you do want to talk design - take into account why people have stated they use mithril.

Design is communication. When coming up with a design, try to communicate your interpretation of either that thread or your personal reason for using mithril.

@v4n's font choice may be a little too bold, but its grounded in a personal theory of Mithril, and communicating that:

I think the goal should be a clean & modern design to reflect Mithril

Whether or not you agree with the design, it would be good if other suggestions were grounded / substantive - instead of just being pretty / flashy / eye-catching. @v4n deliberately is not invoking LOTR's typography because it does not communicate the values @v4n wanted to invoke.

I'm not saying I prefer either design - I am saying I prefer the approach of @v4n's design

Please read over what other's have said in #1026 and make your design reflect and communicate those sentiments.

That said, I really do think this isn't the sort of work that should be handled by a group, it should be an iterative process handled by a single designer who takes responsibility for a particular vision.
But if we are all going to discuss design, we need to go deeper or we will just bike shed unproductively eternally.

Also, I am fairly sure (could be wrong) @ACXgit is already tasked w/ the redesign by @lhorie.

[sebastiansandqvist]

@JAForbes You're right about my proposal not changing anything about the current site. The purpose was partly to explore a new visual direction (since much of this thread is about establishing some kind of branding for Mithril) and partly to say that I think the current layout does a lot of things well.

A github issue isn't the best place for a redesign to take place, though, and if there is already something underway handled by a single person then that is fantastic--in that case either this thread is unnecessary or can help give that designer some ideas. I don't think anyone here approached this with the expectation that the final logo/slogan/design would be their proposal, but rather that this would be a place to share ideas, whether visual and conceptual.

If ideas for the design of the site aren't open to the community, then that is fine, but I was quite excited by the thought that an open source project could be designed by its community. This thread was the first I've seen of its kind.

Your critique that I didn't explain any of the decisions I made visually is totally valid, though. So: The thin but uppercase text was what came to mind when considering "light-weight but robust". The color change was fairly arbitrary, but was from the idea that in Lord of the Rings, Mithril is a light purple-blue metal. That said, I steered away from LOTR in choosing a typeface because the reference really has nothing to do with Mithril itself. For the change in the icon in the logo, I wanted to strip away as many lines as possible while keeping the structure of it mostly the same.

In general, though, unless we really end up bike shedding or stepping on another designer's toes here, I don't see any cause to preemptively halt the discussion or discourage future posts. At least not this early.

[JAForbes]

@sebastiansandqvist Sorry for singling you out, I really wanted to make a more general statement. I like your reasoning! :) I also like your design. Your design was so visually pleasing that it exemplified the point I was trying to make.

It may seem I was pre-emptively halting a discussion, but a) I don't have control over anything and b) there is a lot more context, both in the previous thread and in the original gitter discussion that led me to state my case.

This thread seemed to be continuing a trend toward's attracting users, instead of communicating what mithril is and why it is valuable _in order to attract users_. And I wanted to state that I think that is problematic for a number of reasons that have already been discussed at length in #1026.

Reading over the comments I already see a couple bike-shedding comments taking place. Discussion that is purely about personal taste instead of a justification based on communicating is always going to be bike shedding. So if this thread is going to be productive, any criticism should revolve around what you want to communicate and why that design is or isn't successful in communicating that.

I think there are many reasons why it is probably impossible to design by committee. But I have absolutely no control over this or any discussion, just stating my position. So if people think the case I'm making is invalid, that is completely fine.

There are some fine design minds in this community so perhaps the discussion could be productive. I am just noting my scepticism and suggesting a productive methodology for discussing design.

[v4n]

@sebastiansandqvist nice design, definitely visually appealing. Glad you added some reasoning on your second comment.

Echoing what @JAForbes mentioned, it's important the brand communicates what people should expect with Mithril. Mithril has a lot of good attributes, unfortunately not all of them can go in the same design (e.g. powerful (thick font) vs lightweight (thin font)).
We need to prioritizing what are the most important attributes and message we want to embed into the brand.

Personally I like where @sebastiansandqvist is going. Just one comment: In the top navbar the symbol & 'mithril' text feels a bit unbalanced due to the symbol being thicker.

[JAForbes]

@isiahmeadows JQuery is a prime example of what I'm saying. Yes the design is ugly, but the site communicates well, and therefore it is a success.

Whether its the corporate support, the advertisement for sibling libraries, the bold icons referring to cross browser and CSS 3 compliance, The JQuery _Foundation_ and mentioning that it is used by "millions of people", even the link to _Support_ It's all completely on message: JQuery is a safe, proven bet that is easy to use.

Yes it mentions being fast, and it has code samples etc. But most of the website is about the above assertion.

And from every angle, it is a better website than mithril's despite it's subpar aesthetics.

And the messaging isn't just the text content, knowing your message informs your; layout, palette, font everything. You have to start with your message, it can't be tacked on at the end.

An example. Considering their message is "reliability" and "ease of use":

Font

Italics suggest fast, and flexible. It fits into the message of ease of use and extensibility.
But the font-weight is actually pretty thick, which suggests reliability and strength.

Blue Tones

Blue is the colour of the enterprise. There have been studies that a salesman wearing a navy blue suit will sell more than a salesman wearing another colour. Blue is the colour of IBM, Intel, HP, Dell, HE, AT&T, Microsoft and on and on. Blue suggests safety and strength.

This is completely on message.

When you look at the site: https://jquery.com/ think about what it is trying to communicate, and how successful it was. I personally think JQuery is a solid pitch at the demographic it is targeting.

JQuery is targeting the mainstream audience that doesn't know or care about Javascript, or Virtual DOM. They want to ship a product and they want it to work. They are choosing this library for business reasons. In my experience, enterprise doesn't even care that much about performance, so there is no reason to elaborate on how fast JQuery is. There is no reason to have benchmarks given the audience and the message.

Now Mithril doesn't necessarily want to target JQuery's audience, or Haskell's audience, or even React's audience. We need to determine who that audience is, and what we want to say to them.

That is why every decision in the design has to be focused, targeted and _communicating_. And that is what #1026 is all about.

[aardno]

@JAForbes Yes, it is a strange approach, but as your belief is that design attracts users, my belief is that design attracts community. Criticizing just to criticize is not some kind of solution to anything. I'm not suggesting this is the best way to discuss redesign, but from the looks, this approach is sparking a fair amount of discussion and promoting ideas, nothing deconstructing.

Although, I have spoken with a few of my buddies who've been using mithril for around 6 months in production, and they have said they use it because "It's simple, function-based, and the least opinionated [Virtual DOM JS framework around]". If you wanted a why-to-use-mithril quote, I believe this is what you are looking for.

I'd also say that the aspect of redesign matters more than what is redesigned. The core truth that the community is involved is adventurous, yet pleasing.

I personally believe that this is a discussion and in no course a final answer. The majority here are Mithril developers while at the same time this is not a web design community, so we are in a valid argument, but probably not here. Let it take it's course, there are a million ways to approach a problem, this may be a great way.

@sebastiansandqvist very nice, I think the code bit should be closer to the top of the page to show what Mithril is, but it's cool.

[aardno]

I also need to express that to compare Mithril to jQuery, we have to account that jQuery has/had no reason to promote growth as they have been the dominant JavaScript library and are still holding the grail as the direction to take to learn JavaScript. They are just references to what may or may not be a right way to express Mithril. I don't think there is an overuse in a particular color, nor is there a one true answer as to why people want to use Mithril.

I will take a whim to say that these taglines like VueJs and Mithril's current are not working very well because they seem biased (the frameworks are trying to express why they're better), opposed to Preact's objective look on their library, but of course the name helps. Taking how GitHub dominated over SVN, developers want and need tools that don't get in their way, fast is just a bonus.

[cleacos]

Other proposal logotype with color (w/reversed) and a new slogan:

[JAForbes]

@Javacodia I love a lot about this for so many reasons!

• "Light-Strong" playfully summarise the exact sentiments espoused by so many developers
• It is playful, which gets to what @Bondifrench said, about Mithril being fun.
• The logo echoes the scalable mithril components architecture, and also reminds me of snow flakes which are light but strong.
• The font is strong _and_ light, thick _and_ thin
• The colour is fresh, like mint. It feels professional without being conservative. Strong without being _heavy_
• I like that the slogan says _The_ instead of _A_. It's confident.

A few critiques:

• I personally think we should get away from the word framework for reasons already stated.
• Artisan is clever, but also evokes the hipster scene which is a lot of style and not much substance, which isn't mithril at all. Something to consider.
• I think that slogan could pack even more message into it. e.g. "The Light, Strong JS library for building Applications", or "The light framework for building strong applications". Explicitly state what it does, instead of assuming the culture can fill in the gaps.

Great!

[orbitbot]

I’m a bit confused by this issue and the discussion so far. Not that I wish to step on anyones toes and my intent is certainly not to offend anyone, but I feel that the whole discussion so far is bikeshedding. We’re almost literally discussing the color to paint the shed 😀

Looking at the current home page, I feel that a redesign would be good, mainly since it doesn't pass an important test at first glance: credibility . I've mentioned these on the gitter chat a few months back:

• multiple dates(blog posts, footer, tweets) are from 2014
• other js frameworks such as fe. vue.js / pouchdb / … - set expectations to what modern documentation and homepages might look like

Almost any redesign will fix issues like these, and is essentially already achieved by good "lick of paint" approaches like @sebastiansandqvist 's. I don't feel like there's too much point in discussing the particulars of specific suggestions.

Some other comments are closer to what I would see as a useful discussion to have: spitballing content for the website, and _how to present_ the usefulness of mithril in an effective manner. In my experience it's actually easier to design around constraints, so exploring the contents of the site would be the most useful thing to do (at least until the rewrite is actually _finished_ 😉 ).

In the spirit of _Stealing good ideas from other places_™:

• React (and others) have live coding examples on the home page https://facebook.github.io/react/
• Maquette has a nice tutorial for beginners: http://maquettejs.org/tutorial/01-intro.html
• ...

Other useful things that people from different backgrounds would appreciate is probably "Example of Mithril + X" with other popular js libs like Redux, Cycle.js, Flyd, whathaveyou, as well as "Mithril for Angular developers" or "How is Mithril different from X". I think it would be good to acknowledge that there will be site visitors that have no idea of what vdom is, how to use React and so forth, and make a decision to try to provide answers to their questions. Of course, above the fold slogans and colors are important to catch attention, but that's hardly where the meat is.

[Bondifrench]

I'm a bit into machine learning, there is tool that generates a multitude of different logos, one you give it a word. Maybe a few of us can use it to try to get to a nice one?

[isiahmeadows]

@orbitbot

I’m a bit confused by this issue and the discussion so far. Not that I wish to step on anyones toes and my intent is certainly not to offend anyone, but I feel that the whole discussion so far is bikeshedding. We’re almost literally discussing the color to paint the shed :smile:

Quite literally, that's the whole point of this issue. :wink:

[...] mainly since it doesn't pass an important test at first glance: credibility.

I agree. It could use a _lot_ of improvement in that area.

Some other comments are closer to what I would see as a useful discussion to have: spitballing content for the website, and _how to present_ the usefulness of mithril in an effective manner. In my experience it's actually easier to design around constraints, so exploring the contents of the site would be the most useful thing to do (at least until the rewrite is actually _finished_ :wink: ).

Due to the bikeshedding nature of this bug, it may take that long before we really get an idea of the design in the first place. Conceptually, the rewrite isn't going to be a massive difference from what already exists. It's just going to be a bit smaller in scope, with several things like m.request, m.route, and m.deferred/m.sync going away in favor of built-ins and external equivalents instead (window.fetch, new Promise and Promise.all, and an external module).

In the spirit of Stealing good ideas from other places™: [list of tutorials]

Yeah...we _really_ need to have live tutorials and other resources for beginners. We really need to have a lower bar for entry so people can learn better.

Other useful things that people from different backgrounds would appreciate is probably "Example of Mithril + X" [...], as well as "Mithril for Angular developers" or "How is Mithril different from X".

That would be useful, as well. I think @lhorie could really help with the "Mithril for Angular developers", since he himself was working with Angular when he wrote this framework (that his company later switched to). Oh, and for your vdom addicts, a "How is Mithril different from React" is pretty much obligatory.

// React + React Router
import {Component} from "react"
import {hashHistory} from "react-router"
class TagSearch extends Component {
    getInitialState() {
        const tag = decodeURIComponent(
            hashHistory.getCurrentLocation().slice(5)) // /tag/

        return {
            tag,

            // A null tag is valid.
            fail: tag != null && !validateTag(tag),

            // Set the initial value based on the URL.
            value: tag != null ? tag : "",
        }
    }

    onsubmit(e) {
        // Just in case the browser has already dropped the legacy
        // versions or doesn't support the newer version.
        if ((e.which || e.keyCode) === 13 || e.key === "Enter") {
            e.preventDefault()
            e.stopPropagation()

            if (validateTag(this.state.value)) {
                hashHistory.push(
                    `/tags/${encodeURIComponent(this.state.value)}`)
            } else {
                this.setState({fail: true})
            }
        }
    }

    render() {
        return (
            <div class="tag-search">
                <label>Search for tag:</label>
                <input type="text"
                    value={this.state.value}
                    onInput={e => this.setState({value: e.target.value})}
                    onKeyDown={e => this.onsubmit(e)} />
                {state.fail ? (
                    <div class="warning">
                        Tags may only be a comma-separated list of phrases.
                    </div>
                ) : null}
            </div>
        )
    }
}

// Mithril (rewrite)
import m from "mithril/render/hyperscript"
import createRouter from "mithril/router/router.js"
const Router = createRouter(window, "#")

const TagSearch = {
    oninit({state}) {
        const tag = Router.getPath().slice(5) // /tag/

        // A null tag is valid.
        state.fail = tag != null && !validateTag(tag)

        // Set the initial value based on the URL.
        state.value = tag != null ? tag : ""

        state.onsubmit = e => {
            // Just in case the browser has already dropped the legacy
            // versions or doesn't support the newer version.
            if ((e.which || e.keyCode) === 13 || e.key === "Enter") {
                e.preventDefault()
                e.stopPropagation()

                if (validateTag(state.value)) {
                    Router.setPath(`/tags/${encodeURIComponent(state.value)}`)
                } else {
                    state.fail = true
                }
            }
        }
    },

    view({state}) {
        return m(".tag-search", [
            m("label", "Search for tag:"),
            m("input[type=text]", {
                value: state.value,
                oninput(e) { state.value = this.value }
                onkeydown: state.onsubmit,
            }),
            state.fail
                ? m(".warning", [
                    "Tags may only be a comma-separated list of phrases.",
                ])
                : null,
        ])
    },
}

Of course, above the fold slogans and colors are important to catch attention, but that's hardly where the meat is.

If we don't have the audience's attention, they're never going to see the meat. When you're trying to persuade someone, you have to have their attention before you can persuade them of _anything_. Otherwise, you might as well be trying to convince a brick wall to move.

[isiahmeadows]

@Bondifrench I wonder if it's me, since it's generating mostly irrelevant and/or not very good logos. :smile:

[spacejack]

Things I like about @sebastiansandqvist's design:

• The blue is a nice colour. The gradient is _just_ enough of a hint at something metallic, which is probably about as far as any kind of "mithril" analogy needs to go. I find that particular shade/gradient suggests a very nice material as well.
• My favourite font choice so far.
• I like the 3 interlocking shapes motif. I'm not sure what it was originally intended to suggest, but to me it says M V C. I much prefer @sebastiansandqvist's shapes to the circles. Much more elegant IMO.

[orbitbot]

@isiahmeadows

Due to the bikeshedding nature of this bug, it may take that long before we really get an idea of the design in the first place.
[...]
If we don't have the audience's attention, they're never going to see the meat. When you're trying to persuade someone, you have to have their attention before you can persuade them of anything.

I guess my main point is that content design != graphical design, and I see the former as currently 1) more important and 2) actually possible to iterate right now on multiple levels even without a completed rewrite and a graphic design (which will in turn benefit from the restrictions of the content design). I guess content design should be forked to a separate issue to leave the graphical discussion here... (Do all the forks! 😉 )

What this issue along with #1026 seems to be (partially) grasping at is the arguments to use to explain why Mithril is great, albeit IMHO in kind of a roundabout way. I definitely agree that we need to grab the attention of potential users, and therefore would suggest that the landing page content should

1. give an elevator pitch (above the fold short buzz, ie. "4.5 KB minified & gzipped", "fastest view framework on the blocks)
2. provide the defendable short arguments to _why mithril?_ (instead of x)
   
   
   
   • essentially what arguments can be used to convince you / your colleagues to try mithril
   
   
3. be a starting point for tutorials, further documentation

Other parts of the site could then be dedicated to

• getting started tutorial
• example use cases
• how is mithril different to x
• ...

Essentially the full structure (on a feature/bullet point level) of the site can be described in one or more wiki pages and improved on, as well as start to flesh out actual text content. One (laborious) community-driven approach to the design process might be to implement the site with basic structural CSS which then can be iterated on by anyone inspired to try out different graphical design ideas, not that I'm sure that's actually in anyone's interest.

Ps. I also like @sebastiansandqvist 's logo the best so far. 😄

[ArthurClemens]

I concur with @orbitbot's points. Content design is more important at this time.

Points I would like to add to the landing page:

• A short description what Mithril is about, before moving to the elevator pitch and the why
• More convincing arguments: who is working with Mithril

[aardno]

@orbitbot I don't think content and UI design need to be separate and in many cases need to be combined. For example, content needs to be placed in certain spots, but without a UI, what content ideas are available?, and vice versa.

To clean up a bit, it looks like

• @sebastiansandqvist has a strong majority for best look, with a few critiques
• @Javacodia showcases a great contrasting feel which is exactly what mithril gives: simple but complex; unobtrusive but automated redraw; etc.
• No good UX yet (I put this here because I personally feel navigating the docs can be sometimes extraneous and over-complex; feel free to argue for no UX)

[JAForbes]

Design is much harder than is being depicted by a lot of these comments.

Separating different disciplines of design arbitrarily will not avoid bike shedding. Bike shedding is just arguing about personal taste as opposed to trying to refine a message.

You can't decide on "content" until you know what you are trying to say. This new content thread will just be people arguing over word choice instead of colours / fonts. It all has to be based on a unified message. Once you have that, everything flows from there.

If you don't know your message and your audience, your content will be less effective.

I agree that designing with constraints is important. I'd take it further, I'd say it is necessary.
But the only constraint that is meaningful is: what you want to say, and who you want to say it to.

Once you have that you can decide on:

• layout: what is emphasised vs what is de-emphasised.
• layout: what lands on the main page, and what is just a link.
• layout: detail vs abstraction
• content: Are code examples important, which ones? Who is reading them and why?
• content: Do we want to seem different ( a risk, but more intriguing ), or similar ( safer, but less interesting)
• content: Logos, Fonts, Colours, I've already covered above how much that is controlled by your
  messaging
• usability: Does the layout work on devices we want to target
• usability: Is this content itself, understandable by our target audience, as opposed to one of us

Everything. It's a much longer list. But hopefully you get the idea. Every decision in every iteration is essentially the same question with a new context: "Does X communicate the message better than Y"

A lot of this discussion makes design seem like a layer cake, where we can just make up each layer as we go along, refining as we go. That isn't going to be the best cake on any axis.

A designer can wrangle all these different concerns, it is their job. It is harder than what is being inferred here. I'm surprised some of the designers in our community haven't already said as much.

Designing anything is a lot like choosing your stack for an application. You can't decide on each layer in isolation, you need to think of the best combination for your context as a whole.

A lot of you seem to want to rush to the finish line. But it's the wrong finish line. Getting their faster doesn't mean you win.

After #1026 settles down, there should be another thread that aggregates those ideas down into a single idea / message. This is the seed that informs every branch on the tree that will take form.

Then there could be separate threads that reference each-other, but are all branching from that core message. If there is disagreement, it can be resolved by deciding which side better communicates the core message. The entire process is streamlined, instead of being a bunch of programmers arguing about fonts.

Perhaps some of you think the message is obvious. But you would be surprised how much different people interpret and value things differently. That is exactly why #1026 isn't asking people what the message should be, it is asking them why they personally use mithril. Because even discussing the message is not productive without having some data to back it up

So, please don't start a content thread. Or any other design related thread. You can't design in silos or by committee. It seems exciting that it is all being done in the open, because it is unheard of.
But it is unheard of for a reason: it doesn't work.

[aardno]

@JAForbes I think you are misunderstanding the issue, the point of the discussion is a conglomeration of efforts to propose what may or may not work. Whether or not anything here will be used is not the issue.

You can't design in silos or by committee.
It seems exciting that it is all being done in the open, because it is unheard of.
But it is unheard of for a reason: it doesn't work.

I would like to see your point of reference.

Perhaps some of you think the message is obvious.

Critique is powerful, conflict is not

[JAForbes]

@rdsteg I am critiquing this process. I am not sure why you think I'm doing anything but that.
I want the redesign to be as productive as possible, and as a member of the community I am critiquing this process because I think it is counter-productive and a waste of a lot of people's valuable time.

This perspective is based on historical precedent and my personal experience.

I would like to see your point of reference.

Well, the burden of proof is on you because it is so rare for design by commitee to work. But anyway here is some recommended reading:

• https://en.wikipedia.org/wiki/Design_by_committee
• https://en.wikipedia.org/wiki/Groupthink
• https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
• https://en.wikipedia.org/wiki/Abilene_paradox

And some case studies:

Look at ~2010 Microsoft, complete disarray, separate divisions that can't cooperate, and yet any one person could see a clear path of unification, but because of the division of labour it simply wasn't possible. Compare it to 90's era Microsoft, they had a single high level goal:
"A computer on every desk and every home". A unified vision that informed every branch of their business, and they were successful.

Most people credit Apple's success to having a clear visionary (Steve Jobs) that could make decisions that no committee ever would. Since his death, they've stopped growing.

Look at Mithril itself. Leo has designed it in isolation, the rewrite happened in isolation. Occasionally he appeared and fielded ideas. But only recently has the rewrite been made public. That is because it is mature enough to be _refined_. And communities are great at that.

Most successful programming projects develop this way. There was 1 or 2 people who designed it, and once it reached a level of maturity it was opened up to the community ( Linux Kernel, Git: Linus Torvalds, JS: Brendan Eich, Python: Guido van Rossum)

Here's Francis Ford Coppola talking about the importance of theme when making snap decisions on set.

When you make a movie, always try to discover what the theme of the movie is in one or two words. Every time I made a film, I always knew what I thought the theme was, the core, in one word. In “The Godfather,” it was succession. In “The Conversation,” it was privacy. In “Apocalypse,” it was morality.The reason it’s important to have this is because most of the time what a director really does is make decisions. All day long: Do you want it to be long hair or short hair? Do you want a dress or pants? Do you want a beard or no beard? There are many times when you don’t know the answer. Knowing what the theme is always helps you.

I remember in “The Conversation,” they brought all these coats to me, and they said: Do you want him to look like a detective, Humphrey Bogart? Do you want him to look like a blah blah blah. I didn’t know, and said the theme is ‘privacy’ and chose the plastic coat you could see through. So knowing the theme helps you make a decision when you’re not sure which way to go.

Source

Here is Douglas Crockford criticising the ECMA Commitee:

On fixing design errors in JS:

The design of the language on the whole is quite sound. Surprisingly, the ECMAScript committee does not appear to be interested in correcting these problems. Perhaps they are more interested in making new ones.

On the output of the committee in general:

Substandard Standard

The official specification for the language is published by ECMA. The specification is of extremely poor quality. It is difficult to read and very difficult to understand. ... ECMA and the TC39 committee should be deeply embarrassed.

Source

Any post-mortem I've read on any successful project has a clear pattern; they had a niche, they had a vision they executed on it.

Communities and cooperation are powerful, crowd sourcing can be powerful, but not with design. Crowd sourcing is great at data collection: (#1026) ) and refinement: (documentation, bug fixes). And at the risk of getting political, the democratic process is a great example of the power of community.

I think you are misunderstanding the issue

I am not misunderstanding the point of this thread. The point of this thread is for us all to suggest ideas for different designs - these designs may or may not be used, it is just a place to have a discussion that could inspire the actual designer.

That sounds innocuous, but it isn't. Even if you only consider the opportunity cost, it is counter productive to invest community energy in a process that has no output.

In these sorts of discussions there also tends to be a trend towards the lowest common denominator. Valid ideas are watered down because there is someone who has a personal preference against it. The community trends towards choosing the safest option ( Group Think ) ultimately, the community chooses an option that is sub-optimal and that no individual would ever have chosen Abeline Paradox.

[dontwork]

I think @sebastiansandqvist has the best idea design-wise. I think if we have a couple of willing people to work on this then they are to jump in and get on.

I think vue has nailed it https://vuejs.org/

[ACXgit]

If I may spend a couple of words on the matter as a designer, I would strongly suggest to focus on the message first. Design is visual communication, once the idea you want to transmit is clear the design follows. Design is functional to the content, so if we aim to the best result we need to clear what the content will be first.

[lhorie]

@ACXgit brings up a really good point (I'd argue it's the most important one). So with that in mind, what things would you guys like to see in the docs for the rewrite?

Here's what I think is the bare minimum necessary:

• API docs (explanation in prose, runnable code examples, signature docs)
• Tutorial for beginners (installation, simple application)
  
  
  
  • may be more than one tutorial, if it simplifies explaining various parts of the API
  
  

Other things I think would be nice to have

• architectural styleguides, similar to angular
• comparisons w/ other libraries and frameworks
• benchmarks
• tutorials for hooking to various libraries (e.g. bootstrap, dragula, RxJS, etc)
• tutorials for x-to-js languages (e.g. typescript)
• lots of examples of various complexities

The homepage needs to prioritize things that are differentiators for someone coming from a background of jQuery and/or another framework (likely Angular 1 or React). I'm thinking:

• showcase easy installation and super straightforward sample code
• highlight simplicity in some objective ways
• who is using it

Benchmarks and code size are the two things that get mentioned the most on twitter, etc

Any other ideas?

[orbitbot]

Well, that all escalated quickly :wink:

I don't think content and UI design need to be separate and in many cases need to be combined. For example, content needs to be placed in certain spots, but without a UI, what content ideas are available?, and vice versa.

I would emphasise the other way, if there is no planned content, how can you design a meaningful UI?

No good UX yet (I put this here because I personally feel navigating the docs can be sometimes extraneous and over-complex; feel free to argue for no UX)

Good comment, what are specific issues with the documentation?

You can't decide on "content" until you know what you are trying to say.

I believe that a way of _discovering_ what you are trying to say is to try to write some content to see if it actually comes out well. In the process you might discover what parts are lacking.

This new content thread will just be people arguing over word choice instead of colours / fonts. It all has to be based on a unified message. Once you have that, everything flows from there.
[..]
If you don't know your message and your audience, your content will be less effective.

I agree that there is a need to figure out what "The message" is, as well as identifying the audience to be able to communicate that correctly.

So, please don't start a content thread. Or any other design related thread. You can't design in silos or by committee. It seems exciting that it is all being done in the open, because it is unheard of.
But it is unheard of for a reason: it doesn't work.

What I fail to understand here is how a content thread would be anything else than trying to figure out the message and how to tell that story, in a more ordered fashion than a (this) discussion that mainly is about ideas for the graphic design. I resent talking about "The Message", "The Design" and "The Content" in abstract, because it just leaves everyone believing they've understood everything in the same way without that actually being remotely the case. Making things more concrete will allow for a more meaningful and time-effective discussion.

Essentially I don't see how any of these things in actual fact are in conflict with each other and could not effectively be managed in parallel, but maybe my experiences so far are outliers. I think this is mainly a case of misunderstanding and assumptions, I'm sure we can all get along.

Edit: @lhorie & @ACXgit commented in the meantime I was typing this up at work, but I'll leave this here anyways.

[lhorie]

Guys, I'm not really interested in a discussion about how to design a site _in general_. I'm more interested in what kinds of things we could have in the site to make it a good resource, and interesting ways to show priority points in the homepage.

Discussions about usage of color and styling elements are welcome too, but in my opinion, they are secondary to the goal of making the site relevant and engaging for users

[JAForbes]

@orbitbot

What I fail to understand here is how a content thread would be anything else than trying to figure out the message and how to tell that story, in a more ordered fashion than a (this) discussion that mainly is about ideas for the graphic design.

The difference is, such a discussion would be an aggregation of data instead of people debating their own personal preferences. So it's straight forward, there is a constraint, you can make a case but it has to refer to raw data.

I resent talking about "The Message", "The Design" and "The Content" in abstract, because it just leaves everyone believing they've understood everything in the same way without that actually being remotely the case.

That is the precise reason why deciding on a message is important. So we can make concrete decisions instead of abstract one's. So we can have a goal that focuses discussions, that simplifies debates. The Francis Ford Coppola quote I posted above is a great example of how knowing your theme/message expedites the design process.

I believe that a way of discovering what you are trying to say is to try to write some content to see if it actually comes out well. In the process you might discover what parts are lacking.

This is the best way to design anything as an individual. Instead of writing a big design document, just try something, work with the grain. But this process doesn't work as a collective because we all have own interpretation, connotations and value systems which makes thorough exploration of your own harder.

@lhorie

@ACXgit brings up a really good point

(Correct me if I'm wrong @ACXgit), but I think @ACXgit was agreeing with me. Suggesting content right away, or suggesting particular aspects of a design before you know your theme/message harms communication in the long run. It's so important to have a consensus on what we are trying to say, ahead of time.

Guys, I'm not really interested in a discussion about how to design a site in general. I'm more interested in what kinds of things we could have in the site to make it a good resource, and interesting ways to show priority items in the homepage.

The only reason I'm talking about design in general is to underscore the importance of the process.
If you would rather jump to the end of the process, of course you can, it's your project. But I strongly believe if you do, the existing problems with the website will not be solved.

[lhorie]

@JAForbes I think figuring out the scope of the content is the next logical step. I'm going to risk sounding like an dictatorial ass but I actually disagree that we need consensus on the message. Different things are important for different people and you can never make everyone happy, and saying we need a message is not very actionable. What contributors need to keep in mind are the goals of the site.

The goal of the homepage should hopefully be fairly obvious: to draw people to try Mithril. Even if most of us think aspects A and B are Mithril's true strengths, there's no point preaching to the choir, and simply saying things like "it's simple" or "it scales" is just going to fall on deaf ears (even if those claims might be technically true).

To get people on board, the homepage content has to address the audience's pain points: Why should busy-on-a-deadline-Bob be using Mithril when they can pick Angular or React? How can we erase common doubts in sceptics? What can a cool kid brag about? These may or may not be things you and I think are important or even valid points, but the points need to speak to the audience. One way to put yourself in the audience's shoes is to ask "what would the Aurelia/Vue/Ampersand homepage need to show to convince me to try them?". One could even go around the office doing that exercise to get different points of view.

Once a potential user decides to make the commitment to spend 15 minutes on a tutorial, the quality of the content will then have to speak for itself. A learn-the-whole-damn-thing-in-thirty-minutes tutorial is something people have used as bragging points in the past, and a in-depth section about integrating with dozens of real life and cool-kids libraries is a good way to signal quality via a go-above-and-beyond tactic. A solid section on architecture is something a lot of people would appreciate.

I'm looking for other ideas, especially ones that are more creative and engaging. Experiences with other sites would also be good data points.

[JAForbes]

@lhorie

I'm going to risk sounding like an dictatorial ass

Haha not at all! It's great to get you to weigh in. In fact, my entire point is there needs to be a single direction. Dictators help with direction.

I think you are imagining I want us all to agree on some vague hollow platitude like "It's fast". I don't want that at all. There doesn't need to be a consensus in the sense that we agree, there needs to be an consensus that a decision has been made on what to focus on (by you or someone else). #1023 was meant to aid that decision.

Skipping into actual application without having that decision / focus, is just going to lead to discussions with no destination. As you said yourself, different things are important to different people. That is why it is so important for a set of constraints / parameters on what is on and what is off the table.

Designers often call those constraints, the message, the vision, or the statement. It all sounds a bit like a cult, but hey! I didn't make it up, and its effective.

But if you think you don't need that, then that's cool.

[lhorie]

Personally I understand constraints to be a different thing from the vision, but whatever. Potato, potahto :)

Anyways, here are some parameters:

Artistic:

• Something better than a huge static image as above-the-fold content in the homepage (like Angular.io). Some alternatives: Ruby showcases its ""know-what-you-mean"-ness. Yama showcases development speed. There's lots of room to be creative here
• I don't have a strong opinion on colors or fonts. The main complaint I've heard is that the current design looks dated/ugly. Personally, I prefer minimalist designs, but as long as it has a modern feel and it's easy to read text, I'm cool with it.
• logo: the borromean rings are the logo. Could maybe try playing with stroke thickness and colors? Could at least use SVG instead of the horrible CSS hack I'm using now
• don't evoke LOTR, it kinda distracts from the point
• responsive design

Things I think are important enough to be on the homepage

• Selling points: size, speed, batteries-included. We can probably drop the safety section, since nearly every other framework is on the ball too nowadays
• Validation: famous companies using it, maybe community stats (e.g. gitter subscribers). Drop old twitter comments
• Sample code snippet. Something short but more functional than hello world
• Some sort of comparison with other frameworks. Performance was a big differentiator before, but now maybe installation effort is more relevant? Needs to be visually appealing.
• Calls to action: invite users to dig deeper. Link to tutorials, sample projects

[sebastiansandqvist]

@lhorie What is the current state of the redesign? Is something currently underway, and are you looking to have community input here? It was mentioned that there was already someone tasked with the update. But, if you are looking for community input, what would be most helpful at this stage?

@JAForbes I think that there's a difference between design by committee and making it open source. If I make a pull request, for example, the core contributors determine whether it is merged or not. If my PR is not inline with their vision, of course there was some wasted effort, but often there is a bit of discussion beforehand to prevent that from happening, and that discussion is what I believe this thread aimed to be. We've instead effectively been bike shedding the _process_ here and I don't think that's productive either.

[lhorie]

@sebastiansandqvist: @ACXgit offered to help w/ the designing and I'm probably going to be the one writing most of the documentation. As far as community input goes, I'm interested in hearing about ideas for sections to add in the docs and out-of-the-box ideas (things like the Yama demo as an alternative to a hero static image, as I mentioned above). Viral marketing ideas would be good too.

Re: look and feel, my conversations with @ACXgit so far were mostly about overall style (the thing I mentioned about my liking of minimalist design). He suggested I take a look here: http://beautifulopen.com/ and I told him Vault was the closest thing to what I'd try to implement if I were to take a stab at the redesign myself.

In the interest of moving design forward, we could possibly start iterating on your proposal (since it has the most likes so far). Or others could pitch their ideas. I'd love to see one from @ACXgit at least.

[aardno]

@lhorie Thanks for direction, the original idea was to just get visuals that portrayed ideas. I still hope people can post their ideas visually, but the direction was lacking, sorry.

I have to say vault looks a lot like vuejs, and I would reccomend staying away from the vuejs approach to stay away from creating a stereotype of 'react knockoff'

Slide-out navigation for docs is a definite YES for me. Check out this approach: http://www.material-ui.com/

These are possibly the best docs I have ever navigated through. If anyone has a better suggestion than this, it would be beneficial.

I think open-sourcing the site can speed up a lot of the process. After all, I think the main problem is the current look of mithril. The quicker a first rendition is made, the more people can start to promote the growth.

Possible niches that can throw mithril ahead:

• Mascot

Hello Mithril (like droid but something for mithril)

• Silly/funny/surreal landing

deer head

animated

glorious landscape

• Engaging one-page app

such scroll

A lot here might seem way off-topic, but I feel like mithril has run behind in terms of head-start for it's competition for the virtual dom gold, and I'd like to see mithril grow ten-fold. If nothing else, I can see mithril as 'the door to the virtual dom world' for devs.

_Precaution_: suggestions here are meant to be thought-provoking and stagnating, take little heed arguing for or against anything proposed.

[orbitbot]

After looking through 30-40 js project landing pages, not much sticks out, really:

• karma (still) has a intro video from a conference talk prominently on the homepage
• d3.js has a slightly confusing but nice example gallery as a moving and colorful feature
• vorlon.js has basic moving stuff, makes it seem a bit more vibrant than most other landing pages

... essentially mostly things that are not 100% static, but I left out some exceptionally colorful examples and mascots/logos that are somewhat appealing. Some pages have live examples, but IMHO too many of these are a distraction. Landing page should also be short enough to scroll through, not 200 paragraphs and all the documentation at once.

http://httpster.net/ and https://www.chromeexperiments.com/ always has something or the other for random inspiration, not that these might be particularly practical, eg:

• https://miukimiu.github.io/cassette-tape/

Not particularly viral marketing ideas:

• list Mithril on this page of js frameworks: https://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks
• add logo to favicon

The hamburger menu / slide out documentation thing has some issues, google for "hamburger menu" to find discussions. In the material-ui example @rdsteg linked they've put too much subnavigation there, as an example.

[aardno]

The hamburger menu / slide out documentation thing has some issues, google for "hamburger menu" to find discussions. In the material-ui example @rdsteg linked they've put too much subnavigation there, as an example.

Maybe you'll be happy with something like this then: https://guides.emberjs.com/v2.5.0

Karma's small page might be something to consider, and vorlon shows off a simple animation that works well, good finds.

I knocked the vault design too soon, on second look it might be quite what mithril may be looking for. It expresses 'small' by their 5-word slogan, an easy to understand visual concept of what it does, and some fantastic artwork. I don't know what mithril's future theme will be, but following those guidelines _might_ result in awesomeness.

[Draggha]

@rdsteg I am quite fond of the Ember docs. Just like in MSDN docs or the like you get to choose which version you want. E.g. Mithril 0.2.x or 1.x. All information about 0.2.x is already there, so we could just copy the content into the new layout. But the layout itself should be driven by everything we need from 1.x and possible future content.

Concerning the new homepage itself, I would like to see a focus on sharing wisdom in the form of pure JavaScript snippets. Mithril is not "cooler than the others". That would be disrespectful. Mithril is also not more feature rich. We don't need to sell any buzzwords. When I first read Leo's blog posts I was really delighted. They were short and focused. They didn't show you anything arcane. ES5 + Mithril's structure and Boom! you're done. So my vote goes for a couple of examples to show off what Mithril has to offer right on the front page. On top of that could be Mithril's "Snippets of Wisdom" (like the old blog posts) which we could just link to as a small news-ticker.

Examples

To me Mithril is like the swiss army knife of virtual DOM components. So we should show off what we've got in very concise examples, e.g.:

• a list component: Build a list item component and add it to a list component. Add a click handler to the list item component which can be defined via the list component (this handler will be handed down to the list item component). Add API methods to get the data and to manipulate it. A list item can be toggled between visible and hidden state. -> show a list of names
• a filter component: Build a "search bar"-component with a filter function. Add it to the table container component. Use the list components public API to access its data and filter it using the visibility toggle. -> show the previous list of names, but filtered
• fetch data: Use Github's API to fetch Mithril's contributors and show them in the list. -> show a list of Mithril's contributors (still filterable, of course)
• search via query strings: Use the router to enable filtering via query strings. -> show a list of Mithril's contributors; now not only filterable, but changing the filter also sets a query string in your URL. Changing the query string in the URL also triggers another filter

These short examples can be presented as embedded JSBin _(or whatever service you prefer)_ containers on the page which also briefly describe what the code does. There should be a link to a tutorial explaining what needs to be done to achieve this (and possibly why) somewhere in the description. This way we can build more complex tutorials and show off parts of it on the homepage. Reusing the code from the homepage's example in advanced tutorials builds upon a strong familiarity with the code for users since they already saw parts of it. Advanced topics could then cover:

• adding animations (than again looking at the rewrite this could turn into a beginner friendly topic)
• An SPA with multiple pages where one page has more than one of those example lists from the homepage (core problems: how to get the router to route the pages and handle all query strings correctly + how to isolate the list -> make it idempotent)

Blog

What got most of my attention on Mithril's homepage has always been the blog. The very focused and concise articles helped me get a feeling for Mithril. I'd love for all of us to write concise articles like that as little snippets of wisdom as a seperate part of the blog. The reason for this divide is that the main blog can be used for any news (like conferences, announcements e.g. for new versions, as a stage for partner projects, etc.) and the other part can solely be for these snippets of "mithril in action". This way we would have the old blog, but would'nt mix it with different kind of articles. And it needn't be a part of the docs, so we could also flood it with manuals for e.g. "How to build a data driven component for a firebase backend". It may or may not be a good example and it may or may not help people, but seperating it from the official docs gives us more space to go wild on our ideas instead of linking the official docs with How-Tos for third party libraries.

Docs

The documentation has always been top notch and contained many useful pieces of information. I personally would love it to stay like that and not be "just another fat JSDoc", because Mithril's API surface has always been very small (and the rewrite looks like it will be small aswell). So maybe we could split it up into 2 kinds of docs:
A small JSDoc with the most needed information about the API like e.g.:

• Import path: Which module does this function come from?
• Signature: the function's name, parameters + short description, return type + short description
• Description: A short description of what this function does with one or two examples (only happy paths)
• more information: A link to a overall architecture document or an appendix which explains the functions inner workings in greater detail.

Architecture

Docs for a deeper dive into Mithrils inner workings would be needed. The different redraw strategies of Mithril <1.x are a good example of that. These can be seperated by their overall topics e.g.:

• Routing: What makes a route? What does the router do to your browsers history? History.push vs. Hash? How to use query strings?
• VDOM: The redrawing mechanism in detail -> What does Mithril do to your via hyperscript generated objects? How does a component livecycle look like?
• Templates: How does hyperscript work?

I think I might have overdone it with my musings, but maybe it helps someone to distill something sane from it. Sorry for echoing anything that was said before, but these are the most important bits to me.

_- Jay_

[aardno]

@Draggha +1, a newsletter would be a nice feature too

[rzetterberg]

As a newcomer (a couple of days) to the project I have been reading the API docs a lot. I'm finding it hard to get a good overview of functions parameters when looking at the signatures.

Maybe having some kind of table structure could help to make it more readable? Something like @ArthurClemens Polythene library uses in the docs?

[lhorie]

@rzetterberg that's an awesome idea!

[isiahmeadows]

@lhorie I would agree as well. Polythene isn't the only one - I believe Angular 2 uses that kind of thing as well, and there's several others I can't remember right off.

[lhorie]

@porsager just shared w/ me a logo suggestion: http://porsager.com/mithril

What do you guys think?

[porsager]

@dontwork Did you check out the mono and color version as well? I would love a more elaborate critique ;)

[nordfjord]

@porsager IMHO that logo by virtue of being a box is quite bulky which I'm not sure manages to convey the lightness, and speed of mithril as a framework.

[porsager]

@nordfjord Yeah, I can see that the 3d one might feel a bit heavy.

My idea behind it was actually to outline the simple, modular and composeable nature of using mithril.
I don't think it looks heavy or clumsy in the colored / mono variants. The 3d version was mostly thought of as an interesting way to show the idea behind it.

[orbitbot]

I like the mono version, the others not so much. "superhero" and "lego block" (/building block) spring to mind.

I prefer it over the current one which I see as "chainmail"-y, but @sebastiansandqvist 's version is lighter and has some connection to the current logo. Feel-wise it might look a bit out of place (heavy) depending on how other parts of the home page end up looking.

[ArthurClemens]

I've gone through the logo creation process for an open source project, twice, and at the designer end, so I know how frustrating the process can be (most likely is). Especially developers tend to search for "deeper meaning" (read: superficial image puzzles). Luckily we haven't had that here.

And nevertheless, you need to have feedback.

To me the logo variants (all 3) feel heavy like a building. Somewhat Drupal meets MTV. Perhaps it's my eighties generation.

My personal connotation with Mithril is lighter and more flexible.

But I like the use of the M as main element.

[porsager]

@orbitbot Thanks for the feedback. The superhero/shield angle was actually chosen not only to bring out the M from the shape, but also to fit in a little with the html5 logo
I know leo likes the Borromean rings, and I've also tried to play around with them, but it's hard not to have them look like the Bio Hazard symbol.

@ArthurClemens Thanks for the feedback. I do see the resemblance to drupal and mtv, so the question is if this idea can be worked to something lighter, or if we should look in an entirely different direction.

Not frustrating yet, just wanted to put the suggestion out there, but yeah, with oss, there are a lot more opinions than when working with clients (except when their 10 cats are included in the decision process as well ;) ).

[nordfjord]

@porsager I forgot to mention I absolutely love the font you chose :)

[pygy]

@porsager the perspective used for the logo is reminiscent of wide angle photography which is often used to capture large objects, hence the "heavy" impression it gives.

[isiahmeadows]

@pygy I'd have to agree with that one...

[aardno]

I thought I needed to add this input.

1. Mithril is going under a complete overhaul so something like @sebastiansandqvist's is too similar to the current
2. Expressing what a framework or library has to offer through a logo is very hard to reason about and won't get very far in this discussion. I support a more unique adventure towards a logo, something that none have touched before. 'm()' as a logo could be something to consider if mithril is looking to continue to use that style long-term.

[aardno]

Something like this perhaps

[ludbek]

\m/
Coz Mithril rocks

[ludbek]

Here is a bunch of logos my friend designed on my request. The first right-top one is mine :D but I love the big one at the left. It would look great with the lowercase thin font. I would love to hear your opinion and make it even better if its possible. @lhorie

[aardno]

@ludbek tried making a couple animations real quick, i like the idea

[aardno]

here's another idea i had, i didn't put time into it so it didn't render so well... i'll put time into it if anyone like its

[ludbek]

@rdsteg yeah the logo is a lot easier to animate but once its been selected ;)

[orbitbot]

@ludbek 's design is kinda fun in the sense that it's close to the infinity symbol, so there's even a textual approximation: ∞ MITHRIL. m() is also a nice shorthand.

[ludbek]

@orbitbot yeah it does. The main concept behind the logo is the letter 'm' and two pieces of metals being tangled together(just like in mithril).

[ghost]

When i think of mitrhil, i think of a bar of metal and the first picture which then comes in my mind is something like the minecraft iron bar.
Click for Picture

Something like this could be a easy to remember and simple logo.

[isiahmeadows]

@ludbek I like the idea, but I'm not as sold on @rdsteg's animation ideas...they just feel a tiny bit cheesy (like 99% of all animated logos IMHO, but that's a debate we can discuss elsewhere).

@nbrunch No. Please, let's _not_ associate a web framework with Minecraft... :cry: (Plus, Minecraft doesn't even have mithril as a resource unless you're using a mod that includes that.)

[isiahmeadows]

@nbrunch

Okay...in all seriousness, I just don't think, for a sleek, clean, and powerful Web framework, the intentionally low quality, blocky style of Minecraft and similar would really help advertise Mithril to the general, potentially unfamiliar audience. To be honest, low quality and blocky graphics, even if it's intentionally done well, may undermine the credibility of Mithril as a web framework to some newcomers, especially those in corporate environments already writing at scale or those who are non-technical and looking for some "bright and shiny" thing to "show" their developers and "impress" them, so they end up stuck using it, even if it weren't their first pick.

Even sites like jQuery's and Rails', even though they may not have the best design, are at least clean and professional, and have the ability to draw people in. Python, a language named after the comedy series Monty Python, with a rather eclectic and humor-loving community, still has a respectable, clean, professional website. If you want to see the how clear credibility makes a difference, compare the popularity of Racket and Scheme, two extremely similar languages, to their websites. One of the biggest complaints about Lua is its website and lack of decent tutorials gives the false first impression it's obscure when it's in fact very popular for scripting games and embedded hardware/applications because the language is very simple with simple, first-class FFI bindings, and with the reference VM, tiny and light on memory. It fails to establish the credibility it should, or it would likely be competing with Python directly by now.

We should stick with something at least generally expected of a Web framework, if we want to expose more people to the library. It'll also help a bit more in SEO, which really matters this day and age, no matter what your site is.

[isiahmeadows]

@nbrunch I agree about the animated logos. Some sites can get away with deliberately low quality, and it's possible to create a decent animated logo without making it super cheesy, but it's extremely hard to actually make something interesting with it.

[zserge]

This issue lasts for almost a month and I remember talks about mithril logo or redesign a year ago or so. Honestly, I started using Mithril because I saw it on Github first and read the code. If I saw the current project page - I'd probably though it's some project abandoned years ago - tweets from 2014, everything is square and pale etc.

In my humble opinion it would be better to apply any of the designs suggested above and keep it for a month or so to see how that affects the visitors. Like some A/B testing. I bet that any redesign would improve user experience, so instead of looking for a perfect one - why not to try a good-enough one?

[isiahmeadows]

@zserge That's what we're trying to fix.

[isiahmeadows]

Here's my idea for a logo (I have an SVG saved for each as well):

---

The simple, soft monochrome style represents the simplicity of the framework. Most of us that love Mithril love its simplicity and elegance, and a simple, elegant logo best captures that sentiment.

I chose the text, m(), because that further emphasizes the simplicity and elegance of the framework. It's the most common method you ever call, and it has an aesthetic appeal even in the code itself. You can't get much simpler of an API than that even _with_ macros.

The font, Calibri, was chosen for its rounded edges and minimalism otherwise, because I wanted to make the logo feel approachable and less edgy (no pun intended :smile:). I avoided monospace because I wanted to avoid giving a rigid, structured feel to it.

---

In case you're wondering about the details, here's enough of a description you could fully recreate it your self:

• Size: 300x300 pixels
• Light color (background in light, text in dark): 100% white (#FFFFFF)
• Dark color (background in dark, text in light): 75% black (#404040)
• Font: Calibri, 160 point
• The text is centered both horizontally and vertically inside the logo
• The text is exactly m().

I created it in Inkscape, in case your version differs from what's here.

[hville]

With a dot in the middle, makes an eye and adds space the parentheses

This suggest the _view_ purpose and add some opportunities for custom styling of the dot/logo (e.g. iris, blink animation, iris animation ...)

[lord]

I absolutely love @porsager's logo — to me, it doesn't feel heavy, it feels _sturdy_. It feels like blocks, yes, building blocks. This seems apt, considering Mithril's separable parts coming together to form a cohesive whole, not to mention how it gives developers building blocks to make their app with. It's built from a very simple shape, just a couple of cubes together, reflecting Mithril's simplicity. I love the colors, too.

Also, I think this logo may feel less "heavy" to y'all when used in practice. Some possibilities:

I also queried three random friends (two programmers and a designer) and they all love it.

[darsain]

Apart of coding I also do design, and I've seen this exact logo idea used so many times (honestly at least 3 times I can recall, last time just a weeks ago or so). Not an issue if you don't mind your logo colliding with other projects.

[porsager]

@lord Thanks a lot, and thanks for the great mockups which i probably should have done to begin with as well ;)

@darsain Would love it if you could link to any of them. The first thing i did after doing the very first sketch was to Scavenge the internet for anything like it, and the only similar one i found was one from 2006 which has never been used. If i had found anything that it would collide with I wouldn't have spent the time to go further than the hand sketch.

[hville]

@porsager the blue blocky M version looks like the next letter in the _Nodal Font_.

...or the natural offspring of Nodal+Webpack.

[aardno]

I think it might be useful to suggest a deadline by now; anyone who wants to suggest a logo can be taken into account, but the thread seems to becoming a circular doubt as of now. I suggest issue be closed by friday, so any more ideas or submissions can fork off ideas submitted by then (not a literal github fork).

[isiahmeadows]

@lhorie What do you think of @rdsteg's idea? IMHO I'd give it one more week than he would (Friday next week, not this), but I'm starting to see similar, and the beginnings of an emerging consensus.

[isiahmeadows]

@rdsteg

_(Sorry for deleting your post...I wasn't paying attention and clicked the wrong post + button when I tried editing my post...)_

I'd say close on Monday, there doesn't seem to be many posts throughout the week

There's been a few decent posts during the week, so I'd like to give it a full week. I'll give it until Monday the week after next, unless the conversation fully dies out before then.

[porsager]

@hville Yeah I see the style is the same, but honestly I don't see that as a problem at all?

I extended the kerning on the letters a bit, but this would be my final suggestion..

[hville]

@porsager design is really hard because everybody has an opinion ;). The black and white version works better. Relying on shades of similar luminosity and tint makes it hard to find when scaled down.

I actually liked the old Mithril page. Not pretty, but of the many Javascripts projects around, it was a good example of communicating what, why, how right up front without scrolling or navigating.

[isiahmeadows]

Closing for now. A new issue can be opened later when we're a little more ready.

[aardno]

Uploaded album of submissions here: http://imgur.com/a/PC8I1

[donkeybonks]

+1 for @Javacodia s suggestion (bottom version).

[isiahmeadows]

@kvanberendonck Note that the site is already live with a logo similar to the old one. (I wouldn't be averse to changing it, though.)

[donkeybonks]

Oh I know there's a new site, I was just under the impression that it was not final.

If it is final, then the look and feel of the current site and logo in comparison to some of the wonderful suggestions here gave me that impression (no offence intended, just saying it how it is).

[spacejack]

Here's a design concept I floated on Gitter a while back:

http://www.spacejack.ca/mithril-design/

[tobyzerner]

FWIW I like the current website/branding. I like its plainness and information density.

For newcomers, the first thing they see is "What is Mithril?", and then they can immediately get a taste with "Getting started".

For veterans, most of the time they'll be visiting the website for docs, which are immediately available in the sidebar.

The website is nothing more than it needs to be, which I think is very reflective of Mithril itself.

[donkeybonks]

I think the current website has a home brew feel to it , and as a company that's not the type of feel you want to get from a library before you adopt it.

There needs to be a way to communicate both lightweight/meticulous and enterprise-ready at the same time .

[donkeybonks]

(Because it /is/ enterprise ready, we've been using it since inception to power a cutting edge ERP that translates desktop apps to the web, streaming huge amounts of data through a web socket for client sided data analysis views )

[isiahmeadows]

@kvanberendonck I do kind of get a similar less-professional appearance from it, too, like it hasn't had much design put into it.

[ludbek]

This is my final update.