Closed addyosmani closed 10 years ago
Looping in Dr. @paulirish and @paullewis
Feedback we've heard a few times is that developers see WSK as falling somewhere in-between H5BP and Bootstrap. They like the mobile, perf and tooling focus but the lack of giving them something closer to Bootstrap (styles for everything) is causing a wee bit of confusion. We wanted to stress 'you should focus on customizing WSK with your own styles', but this message doesn't seem to be getting through.
As you know, Google doesn't really have a non-Polymer based UI library. We are actively working on an implementation of Material Design components for the style-guide, but even when it's ready I don't see it offering the same type of thing. That was never quite our intention. Most agencies don't/shouldn't be using Bootstrap for their projects and I think it stops being used when prototyping is over. Am I wrong there?
Do you think there's value in continuing our current push of providing minimal styles encouraging devs to replace them with their own, or are we missing our on a clear piece of the puzzle by not including and recustomizing an existing UI library (Bootstrap, Pure)?.
What are the goals of WSK? I see WSK as having multiple goals.
For the boilerplate, I see that we need to go one step beyond h5bp, but not go as deep as Bootstrap. That means by default all standard elements should look good and work well (buttons, h1's, lists etc) and have a good (simple) layout system all with as little JS as possible whilst making it clear that web developers can and should customize it to their look and feel (it is akin to http://getbootstrap.com/css). This means in the core build we should not go much further than this, we don't need "hero" items, pagination, breadcrumbs and all the other jazz that bootstrap provides.
To get to the utility of bootstrap (http://getbootstrap.com/components/) we need to provide "extras" that are not part of the core build but are incredibly easy to integrate and also simple to get developers to contribute new modules back in to the system. My thoughts on this is that a developer must choose to opt into this therefore the explicit "extras".
To provide a future facing look we need to set out how we want developers to build sites today. I fear integrating "SUIT" and "Bootstrap" and other frameworks because we lose control over setting that direction and controlling how we want to shape the future for developers. For example Grid Systems, they are all horrible but they don't even think about how to integrate with CSS Grid Layouts - We should do that!
re:IE9 and IE8. I understand the concern but everyone is stopping support for IE8, and IE9 stats if I read them correctly are tiny as well. What do we need to do to convince people that IE8 and 9 are not things that they should support (or if they need to, offer a optimized experience - i.e, no breakpoints)
re:SuitCSS. Are we sure we want to be refactoring to this model? It doesn't feel like it fits very well into any sane model of development and readability or future that we are looking for.
re:Grid system. We should absolutely provide a sane and very simple grid system. I don't like the syntax of components-grid. Why not consider something that makes it easy to map directly across to the CSS Grid API.
re:That layout bug. It was fixed, has someone broken it again?
Please don't customize or integrate another UI library.
I personally don't see an identity crisis. I see developers having boxes they like things to fit in for categorization. Then when something doesn't fit they get confused. It seems now you are either a boilerplate, framework, or library. If anything, WSK is just an opinionated boilerplate in my mind.
On the note of IE support. Even MS is dropping support for everything except the latest IE on the perspective platform soon enough. Which means IE9 is supported on Vista only come 2016. Yes two years, but should the project incur some technical debt (on top of project contributors putting their efforts into support) for what most projects using it won't need to support? If people need to support things like IE 8 or 9 then they already have toolsets to handle that, I don't see why WSK needs to be added to the mix.
Most agencies don't/shouldn't be using Bootstrap for their projects and I think it stops being used when prototyping is over. Am I wrong there?
From my experience in IRC (granted, small overall view here) helping people and seeing what they are putting out, Bootstrap is used even in production quite a bit. If it is used properly (LONG shot here), you don't even know it is there for the most part. For example, the current ExactTarget site. A few pieces you can clearly tell are using bootstrap classes from being added in after-launch quickly, but mostly it is hidden well. The problem is people either don't use it properly by using it in mixins to mask its application or they are like myself and can't design so they don't care to do anything differently.
I'm with @Garbee; I see WSK as an opinionated boilerplate: a mobile-friendly, perf-centric successor to H5BP. I don't see it as anything akin to Bootstrap though, but maybe that's just me.
In terms of styling I think it would be a mistake to ship with Bootstrap or even anything Material; it limits its usefulness for those who don't want styling, unless those things are super easy to remove. And in my head there's little-to-no difference between shipping with "basic" styles and full-on kit. If you don't want it you're going to be frustrated, or if it's not quite what you want you'll feel similarly ("I have to go off and get X to replace the default styles.")
For me, a perfect world solution would allow someone to get WSK with Polymer / Bootstrap / Material / some other compatible UI, essentially as an extension to their download, not bundled in. Much as I don't need all Modernizr tests for each project and can custom build to suit my needs. But if we're not going to go there (and I can see why we might not want to) then I don't think there's anything wrong with saying WSK is a an opinionated starting point for your project that doesn't ship with any styling.
I see WSK as an opinionated boilerplate; a mobile-friendly, perf-centric successor to H5BP. I don't see it as anything akin to Bootstrap though, but maybe that's just me.
:+1:
I wouldn't go as far as calling it a successor to the H5BP. The H5BP still has a really nice place for being an extremely minimal starting point. I see WSK more as a great companion piece. It includes not only some decent default style to have some look, but also good workflow tools baked right in. Where H5BP uses straight CSS and JS to be the most compatible, WSK uses Sass and Gulp by default to aid the developer in their workflow and maintenance.
Developers should look at the two solutions and decide for themselves what they want to start from. Some projects may align well with what WSK provides, while other projects you may be better off grabbing H5BP and starting from that.
I wouldn't go as far as calling it a successor to the H5BP. The H5BP still has a really nice place for being an extremely minimal starting point.
<bikeshedding>
I really want to see a developer shift to thinking about high performance, mobile-centric sites and apps, and I think WSK is the best starting point for that. There are some fantastic things inside of H5BP, particularly its .htaccess file, but overall its emphasis feels desktop-centric to me. I wouldn't use both H5BP and WSK, so I don't know how realistic it would be to consider them companions.</bikeshedding>
I wouldn't get too stuck on the wording: successor
=> superset
focused on mobile perf.
I really want to see a developer shift to thinking about high performance, mobile-centric sites and apps, and I think WSK is the best starting point for that.
:thumbsup: Also imo it is a better starting point for people to learn from since it has more substance to it than H5BP.
Thinking on this, I went and looked over the current readme to see how the current message aligns with this though. It could use some work. For example the overview opens it up as generally multi-screen oriented. Then performance is only mentioned way down below everything else. One good step to trying to solve developer understanding would be to improve the overview section (which is probably what people initially look to for the projects goals.) For this point I made issue #362 for discussion on improving that section.
Sorry to barge in, but just wanted to add my unsolicited $0.2 as a representative of the wsk user base. As a front-end developer/designer I use wsk more for the build structure than ui design. I choose to try out google web starter kit (in order of importance):
Obviously, the wsk styleguide was built for web fundamentals but the styleguide code (but not structure) would be totally customized for most projects - for example to create the Polymer website. I thought this was intentional. Using wsk saved me time with base styles/naming/structure and quite a bit of time with tooling - especially the app/dist structure for easier testing/deploying. It seems to be changing rapidly, but hopefully when it slows down there will be more explanations in the wiki/docs. The better the docs the lower the barrier of developer skill required - who need it the most.
I see wsk as a starting point for custom designed Styleguide Driven Development or at the very least a modern architecture starting point, allowing you to encapsulate projects for easier sharing/testing/deployment.
I really want to see a developer shift to thinking about high performance, mobile-centric sites and apps, and I think WSK is the best starting point for that.
Please add accessibility to that list. The buttons need focus styles! Checkboxes, ranges, and all other components also need to be accessible from the keyboard and assistive technologies. Use native components wherever possible, and add correct ARIA roles, states and properties to fill in gaps. It is important to lead by example, even in styleguides.
@marcysutton :+1:
Thanks to everyone for their comments and feedback.
I'm in agreement that we shouldn't add in an existing CSS library and stay lean. It's actually great to see that users like @tonyjessup have found our approach to using our minimal styles as a baseline you replace useful. Let's stick with that approach moving forward.
@marcysutton I'm glad you brought that up. For a lot of the work we've been doing in #296 we've been trying to keep accessibility in mind, but we would absolutely love (if you have time) some more issues opened up about specific areas of accessibility we could improve on.
We definitely want to get better there.
Is there a need for a grid system? I implemented one: https://github.com/Itrulia/Frost--Grid (The docs aren't the best, I am going to create a demo for it tonight).
You do not have to include it was a dependency, if you want you can rehost it in any repository and maintain it there (I am willing to help ofc).
The advantage I see in my library is that you don't have to create multiple rows, you can work with 1 since I am not taking use of :last-child
or :first-child
.
Hi, i believe in the use of mixins to improve the productivity of modules and components: Grid, Colors, UI etc. I created Frontendler http://frontendler.com.br with that in mind, use mixins and few settings to do things that previously would have held on much longer. The grid system in the frontendler allows to create apps with less time and with a quality code. Even if it is not used in the WSK fully, I believe the approach will gain more productivity and simplicity in project. I hope I have helped! :D
Hey folks. We do indeed intend on shipping a grid with Web Starter Kit. The Material Design spec has grids for the Web coming and as soon as they're published we'll be implementing their suggestions.
@addyosmani sorry for the response with "advertising" srsr but I really believe in this form of development , the bad point is that we are hostage to sass , but on the other hand we have several other advantages to this approach :
$grid-breakpoints:(
phone: 100% max 480px,
tablet: 100% min 481px max 1024px,
desktop: 1025px min 1025px,
);
@include grid-col(3,12);
@include grid-col-breakpoint(phone,12,12);
@include grid-col-breakpoint(tablet,6,12);
pallete maps
$palette:(
red #fde0dc #f9bdbb #f69988,
pink: #fce4ec #f8bbd0 #f48fb1
);
and his use
.element{
color: pallete(red,50);
}
.element{
color:#fde0dc;
}
warning: this features (maps) only supported in sass > 3.3
Feedback on the project from reddit:
This is legit feedback. I think to address this we need to improve project messaging (as well as defining an actual grid). We'll also want to decide just how much visual UI we provide vs. being more prescriptive using our own library (Material++) or an existing one.
@PaulKinlan @gauntface do you have any thoughts on us defining a new minimal grid system, opting for an existing one or using something like https://github.com/suitcss/components-grid which compliments the SUIT CSS refactor?
I think that going back as far as IE8 is asking a little much, but we could do IE9. We've already been testing our prototypes for Material Design in IE9 and could extend that to more extensive IE9 testing. I want to make sure that folks in agencies don't see IE10 in our readme and are instantly turned off using the project.
This is in reference to the homepage. I believe this was fixed over on https://developers.google.com/web/starter-kit/ - @ianbarber do you know if a fix for the grid was deployed?