Closed aardno closed 8 years ago
aardno
commented
8 years ago 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).
@Morklympious proposed:
Removed taglines, I don't see the need for mithril to re-brand
ArthurClemens
commented
8 years ago 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
commented
8 years ago 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
commented
8 years ago 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.
dead-claudia
commented
8 years ago @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
commented
8 years ago @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
commented
8 years ago @v4n and @drew11b I like your ideas, I took some time trying to steal ideas from Haskell's site.
sebastiansandqvist
commented
8 years ago Some ideas on the visual direction this could go in:
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:
dead-claudia
commented
8 years ago 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
commented
8 years ago I, for one, like @sebastiansandqvist's proposal.
Bondifrench
commented
8 years ago @sebastiansandqvist 's proposal looks best so far, should see if there are other proposals anyway.
JAForbes
commented
8 years ago @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
commented
8 years ago @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
commented
8 years ago @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
commented
8 years ago @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
commented
8 years ago @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":
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 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
commented
8 years ago @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
commented
8 years ago 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
commented
8 years ago Other proposal logotype with color (w/reversed) and a new slogan:
JAForbes
commented
8 years ago @Javacodia I love a lot about this for so many reasons!
A few critiques:
Great!
orbitbot
commented
8 years ago 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:
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™:
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
commented
8 years ago 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?
dead-claudia
commented
8 years ago @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.
dead-claudia
commented
8 years ago @Bondifrench I wonder if it's me, since it's generating mostly irrelevant and/or not very good logos. :smile:
spacejack
commented
8 years ago Things I like about @sebastiansandqvist's design:
orbitbot
commented
8 years ago @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
Other parts of the site could then be dedicated to
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
commented
8 years ago I concur with @orbitbot's points. Content design is more important at this time.
Points I would like to add to the landing page:
aardno
commented
8 years ago @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
JAForbes
commented
8 years ago 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:
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
commented
8 years ago @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
commented
8 years ago @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:
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.
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.
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
commented
8 years ago 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
commented
8 years ago 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
commented
8 years ago @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:
Other things I think would be nice to have
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:
Benchmarks and code size are the two things that get mentioned the most on twitter, etc
Any other ideas?
orbitbot
commented
8 years ago 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
commented
8 years ago 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
commented
8 years ago @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
commented
8 years ago @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
commented
8 years ago @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
commented
8 years ago Personally I understand constraints to be a different thing from the vision, but whatever. Potato, potahto :)
Anyways, here are some parameters:
sebastiansandqvist
commented
8 years ago @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
commented
8 years ago @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
commented
8 years ago @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:
Hello Mithril (like droid but something for mithril)
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
commented
8 years ago After looking through 30-40 js project landing pages, not much sticks out, really:
... 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:
Not particularly viral marketing ideas:
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
commented
8 years ago 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
commented
8 years ago @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.
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.:
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:
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.
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.:
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.:
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
commented
8 years ago @Draggha +1, a newsletter would be a nice feature too
rzetterberg
commented
8 years ago 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
commented
8 years ago @rzetterberg that's an awesome idea!
dead-claudia
commented
8 years ago @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.
A fork of issue
Reasons we use Mithril #1026Here 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.