Decoupling of Axis / Roots

[zspecza]

So I got back from lunch with my old man, and decided to give the entire documentation a thorough read.

The inspiration for this decision were the comments made over at the Hacker News discussion on Axis, so I decided to look particularly for anything confusing and I've come to the conclusion that a change needs to be made.

There are too many inter-project mentions of Axis in Roots and Roots in Axis. Essentially, it's all described as one end-all-product, which is made even more confusing because the documentation for each shares the same domain and the same logo.

I propose a change: Keep the same domain, give Axis it's own logo and describe each project as if it had no relation to the other, but keep one small mention in the Roots docs that it automatically ships with Axis.

People looking for a front end CSS framework alternative to Compass/Bootstrap/Foundation are not going to care about static site generation or build tools and vice-versa.

On a much sarcastic lighter-but-still-important note, I believe the design should show off Axis a little more.

[yoshuawuyts]

Any link to the hacker post?

[zspecza]

https://news.ycombinator.com/item?id=5830190

[jescalan]

So I don't disagree with this, but I also don't think that it's worth pushing axis hard as a standalone tool either. Unless people suddenly decide that rolling their own compilers is the thing to do for each project rather than using existing ones, axis isn't useful to the average developer by itself. It's only useful as a part of a build system of some sort -- in this case, the easiest ones are roots and express, both of which are handled by roots generators.

The hacker news post was made by someone else (not me or anyone I know), and the top commenter was confused by the fact that the post was presented as a project's main page, but actually was a documentation page. His comment would have been entirely valid if that had been the roots homepage, but it wasn't. The roots homepage was up on hacker news earlier and had a bunch of upvotes and not a single comment like this.

Now you might point to compass and say "hey compass has it's own page and isn't part of a build system" -- but that's because compass is a build system. Most people refer to it as a css library, but compass is bundled by default with a build system which is part of the same website -- see here: http://compass-style.org/install/ -- it's just prioritized opposite to how roots/axis is: the emphasis is on the css library and the build system is an addition, where in the case of roots, the emphasis is on the build system and the css library is more of an addition.

Not trying to argue particularly in one way or the other, just throwing out some things that you guys might find interesting.

[zspecza]

People looking for a front end CSS framework alternative to Compass/Bootstrap/Foundation are not going to care about static site generation or build tools and vice-versa.

I do like your thoughts, though. But it doesn't change the fact that it caused confusion - and even after your reassurance, those users who commented were still confused. That's a good sign that it's high time to re-word things a little.

I work in marketing and that is my primary field of expertise (despite my passion for being a developer instead), having parents who both own their own marketing research firms and an adamant father who wants nothing more than one of his sons to take over his business when he passes.

What I'm saying is this, you can trust my judgement on this one. Rewording things to make them less confusing and presenting each project as it's own (while still making mention of Axis belonging to Roots, even though the fact that they share a domain name subconsciously enforces this idea anyway), will have a positive impact on the traction both products receive from the community.

You'll see more adoption happening, and garner more feedback and contributions as a result - much like the contributions I've made, you'll start to see best practices and concepts emerging at a faster pace and other developers who need a feature badly or need a bug squashed will try to do that in their own time, leaving you to focus on taking both projects in the direction you envisioned when you first woke up and thought; "Today, I'm going to create something that will boost my productivity as a designer a thousandfold and share it with the world, but not after I make writing style-sheets pleasant.".

You know a lot more than I do about design and development and definitely have the experience behind you to back that up - but analyzing clientele and target market is a first-class language to me, and from what I can see here is that you have two target markets:

1. One who needs the whole package
2. One who just needs faster CSS development

If you weren't targeting these two clienteles, you would have just created one end-all solution. But you made the decision to expand your market, and the only reason I know of that people and companies choose to expand their market is because they want as many people to use it as possible.

So, being consistent and catering to both types of users when presenting your project will be of larger benefit. Designers will go "Ah, ok." and developers who just need a quick static site with a quick way to add bells and whistles will have the same mindset.

[yoshuawuyts]

I'm a big fan of the sails framework and also happen to be a maintainer of the sails-generator plugin for yeoman. I think it would be awesome if we could just do something like this:

sails init
>> choose framework : angular
>> choose view engine : jade
>> choose css preprocessor : stylus
>>> choose framework based on preprocessor : axis
[insert magic here]

Voilá, a custom scaffold to fit your needs.

Yeoman with the grunt build system is a killer combination for me; I think axis is an excellent alternative for bootstrap and foundation, which tend to be more stylized.

On the note of a custom look: I too think that pushing the code quality forward should be the #1 priority right now. Creating a proper brand takes time and effort, considering it already looks good it might be better spent elsewhere. Once all the quirks are resolved and the project reaches a more mature phase proper branding might be a great addition. For now I suggest we keep up the work on the documentation since that's what will determine the usability and aggregation of new users of axis.

p.s. On the note of being a maintainer of the sails generator: I have push rights, but I'm waiting on the sails 0.9 release before I start tinkering.

[jescalan]

Ah wow great comments from everyone.

Declan, you don't need to try to prove your worth -- your thoughts should be enough to prove that alone. This is not a battle for technical credibility, it's an open forum for discussion. I think I understand what you're saying here though, target axis more toward designers. Let me know if that was the wrong interpretation, but it does makes sense to me. Really, I think we need more targeting in general. It's fairly difficult to explain what both roots and axis are to me, because roots isn't just a static site compiler, and axis isn't just a css library -- they both have a little something extra. Roots is moving into a zone where it almost sits in between static and dynamic sites, and axis is sort of in a zone between full frameworks like bootstrap and css-helper-only frameworks like compass.

Any perspectives you guys have on how to describe these tools best would be awesome, and I'd love to help improve the first impressions and make them easy to understand.

So Declan what you mean here is that you are envisioning the axis page almost as it's own landing page rather than a straight up docs page? So if you landed on axis, it would explain what it is, show it off, and have links to the docs and to roots, it's coupled build system. Does that sound more along the lines of what you were after?

Yoshua, the concept of configuring things upfront is definitely interesting to me. In both these projects so far, I have been pushing for making things configurable, but pushing defaults upfront rather than asking you for a decision, then allowing you to change things out down the line if you want. Much of roots is built this way - the defaults are there, but if you want something different you can make it happen.

It seems like that's going to be a bit more difficult for axis, at least if we are trying to accomplish this with stylus alone. We could think about building an accompanying command line tool or something that would allow users to "install" or swap between different frameworks within axis maybe, but that would have to be integrated into something like roots, which would just tie them even more together, which could be a good or bad thing.

On the other hand, if people do want to use other grid systems it's not like it's impossible to do, they can just include it themselves...

[zspecza]

It wasn't so much proving my worth and/or a battle for technical credibility so much as it was simply a means of reassuring you that this decision stems from a calculated thought process and experience, not just something random I decided out of the blue. It's a forcive habit - a lot of people misinterpret the marketing industry and what we actually do, so I very often need to explain the hows and whys. For example - a Marketing research firm does not do branding - we do statistical analysis, measure metrics, market competency and that sort of stuff. It's a type of forensic science if that makes it any easier to comprehend. 😄

As for your interpretation of my point, that wasn't my initial thought, no - but it would certainly be better in many ways. So yes, I guess your interpretation is spot on, haha.

[jescalan]

Even so @declandewet, that kind of qualification doesn't belong here (or in any conversation with rational people). I don't care how old someone is, how much experience they claim to have, etc. In an open discussion, all that's important is the opinions on what we're talking about. If your thoughts come from metrics and experiences, details those metrics and experiences. An opinion must support itself, it cannot be supported by reputation.

So anyways what we've concluded is something along the lines of a sort of refactor of roots.cx/axis so that it's more welcoming to people who land on that page and introduces axis as a css library which can be used with roots (or anything else), linking to the axis docs and roots docs, no? I mean, totally winging it here so any other feedback welcome too.

[zspecza]

Precisely. But I'm sure the Roots page would benefit from a similar refactor as well. :)

[yoshuawuyts]

I think Axis's ideal position is somewhere in between inuit.css and uikit. What I want from Axis is a lightweight, comprehensive framework that doesn't force any style on me, but defaults to something beatiful out of the box. A solid, semantic base with a tiny sprinkle of common components should be enough.

On the matter of changing the landing page: adding a little structure might help out a lot.

base       //lists, forms, grid, etc.
components //breadcrumbs, buttons, etc.
javascript //transitions, tooltips, etc.

Just some food for thought.

As to swapping different frameworks within the Axis framework: I think Axis users shouldn't be worrying about such matters. As good devs we should be the ones providing the right tools for them and document them well (with what version of IE is all of this goodness compatible, does or does it not make us of flexbox, is it future proof? etc.) Most advanced, yet acceptable, hmm (:

[zspecza]

This is landing page worthy body copy 😁 , well done:

What I want from Axis is a lightweight, comprehensive framework that doesn't force any style on me, but defaults to something beatiful out of the box. A solid, semantic base with a tiny sprinkle of common components

[jescalan]

So the javascript piece is something I would like to tackle at some point, but would have to be separate from axis (although the two could be bundled together for marketing), since it's not css.

I think the closest thing that exists is component, but what I'd really be after is a set of minimal rock-solid javascript plugins to cover things that come up a lot much like bootstrap has, but that have very clean public APIs are are not tied to any sort of markup or styles at all.

[zspecza]

Great idea - could be a separate optional project and have browser polyfills in it as well. We should also handle the writing of any RequireJS configs to ge tthem working together, too. :) that's one of the reasons I dislike Bootstrap - doesn't enforce good client-side JS behaviour and so many new "designers" start using it and pick up on bad habits.

[jescalan]

Right, I agree. It does seem like a huge amount of wheel-reinventing, but I very frequently am looking for small components for common purposes and end up sacrificing on exactly what I want, which is a small, self-container, and clean client-side jquery (or not) plugin that works down to ie8 at least.

[zspecza]

Well nobody said you had to reinvent the wheel - there are many libraries that are already great for things like modal windows and other UI components. And there's no shortage of polyfills either: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills