Nicely done, but if you are really trying to be a framework for internal apps (vs a design framework like bootstrap) - I would focus on adding a couple of more admin-like components (such as grids vs tables with the options associated with grids).<p>An opinionated admin framework would be a huge win. For what its worth - semantic-ui.com has a couple of neat compenents that are also worth having (cards, steps/wizards).<p>Watching this project now!
I really like gridforms for dense data-entry forms (<a href="http://kumailht.com/gridforms/" rel="nofollow">http://kumailht.com/gridforms/</a>).
I feel internal business applications can be visually appealing too. People have to look at these things all day, so
why are we so quick to assert that these people are practically robots who can't appreciate comfortable interfaces when we design and build boring apps?<p>Life can look good all over. Don't succumb to this "business is serious and should therefore be dull and boring" stuff.
I wish more things looked like this at work. There's apps that look like native apps, there's bootstrap apps, there's all the custom CSS floating around, there's whatever's new, there's the stock CSS sheet that comes with the plugins...<p>Keeping to principles like this at work or for work environments would make it so much easier to have unity. I'm not saying everything should look like this, but that not everything needs to stand out for the sake of standing out. Using the same app every day undoes the need for over the top "visual cues" and complex overlays and material concepts. We need fast, interchangeable stuff, that works with large amounts of data/fields/etc when the content doesn't fit looking like apple.com. :)<p>I wish you guys luck, and I'll give it a shot the first chance I get.
This is really cool and a nice start. One big thing we are dealing with in our internal app are responsive tables. We display some data in tables, but it almost always looks like crap on a small screen. There are a few different ways to solve this. Sometimes it makes sense to hide or abbreviate columns other times the table should neatly convert to a list. This is tougher.<p>I also like your search & filters design. I did something like this just last week, but I like yours better. ;-)<p>In some places you use semantic class names, like for messages, but for buttons you use colors. Probably better to just stick with a single convention for consistency.
"It goes away with custom fonts" should be "It does away..."<p>Other than that, pretty cool! There may be a space for this...<p>Reminds me a bit of <a href="http://platform.qbix.com" rel="nofollow">http://platform.qbix.com</a> which we built to power <i>social</i> apps (on all devices).<p>One tip: if you're going to make it for business, have the demo document the keyboard shortcuts to get around quickly, like in gmail. Ideally your "front end framework" could have a controller that would accept a keymap object like {"a": "actionName", "r": "someOtherAction"} etc.
I'd like to understand more about the rationale that led you down the path of creating this.<p>In my years in enterprise, user and market research has driven the push to create UIs that are more compelling, that make users feel more at home and comfortable (as they would be with mobile and consumer products), while maintaining a more narrow focus on tasks instead of providing a generic one-size fits all paradigm.<p>This framework stands in contrast to that, making things dull and boring. What caused you to go down this path?
I really like this which was linked from there: <a href="http://kumailht.com/gridforms/" rel="nofollow">http://kumailht.com/gridforms/</a>
This is great - I'm working on internal webapps full time and I often notice how data-heavy apps with high density of information come with their very own challenges that make Bootstrap, Foundation and Co. less of an ideal choice. What looked great in a simple demo, suddenly feels cluttered in boring data grids. Often it turns out that adapting these frameworks to our own requirements, visually and in terms of functionality, is more of a hassle than simply starting from scratch. Which is what I started to do lately.<p>This, however, seems like a great starting point that I will definitely keep in mind for future projects. I'll need to check how easy it will be to customize and extend it, but it's a great first impression.
Great start!<p>One thing that I noticed immediately was the UX associated with the hamburger menu.<p>When the page content gets sufficiently long, you have the potential of scrolling beyond the hamburger menu. To jump to another page, you have to scroll to the top.<p>Potential solutions could be making the hamburger menu fixed to the upper-left corner, or provide UI widget to return to top of page.
I'm really glad I checked out this posting because it led me to the author's other work, which is really impressive. <a href="http://kumailht.com/" rel="nofollow">http://kumailht.com/</a>
Way to go, great looking stuff.
Very nice work. Given the prevalence of Bootstrap and Foundation, it would probably help adoption if there were options with those as the base styling lib.<p>I know there is a lot of work in the custom sass here and this is currently a one-man project. May be a good candidate for a "Roadmap" and "How you can help" section in the repo's Readme.
Everytime I see a new CSS framework with a grid layout (which they all do) I get sad that decent cross-browser support for the CSS Grid module seems so far away...
Lots of nice work put into this, but I think some of the fundamental architectural assumptions are a little regressive. For instance, it looks like the boilerplate expects a lot of server-side template rendering, or minimal dynamic rendering on the front-end. Also, using jQuery and event-oriented JS in general is nice and stable and easy to grok, but in my opinion not forward-looking.<p>I think the front-end world is going more in the direction of single-page apps that primarily use the server side for data-driven APIs. The server-side APIs become way more portable, and the user experience becomes far more responsive. Just because something is internal doesn't mean you don't want data portability, high responsiveness, and low latency.<p>I respect the fact that the approach is opinionated from a front-end perspective. But to counter an opinion with another opinion, data portability and reduced latency from the server justifies all the fuckery associated with many of the SPA frameworks (looking at Angular when I say fuckery). This framework encourages people to stick to the skills they were comfortable with five years ago, and untempered complacency is never a good thing.
khet, you may not be aware but you're violating an HN rule by asking others to upvote your submission [1, 2].<p>1: <a href="https://news.ycombinator.com/newsfaq.html" rel="nofollow">https://news.ycombinator.com/newsfaq.html</a><p>2: <a href="https://twitter.com/kumailht/status/540503967977852928" rel="nofollow">https://twitter.com/kumailht/status/540503967977852928</a>
Some feedback about the preview section:<p>/preview/typography: I was hoping to find out what font(s) I was looking at, but this page contains a history of typography. Looks like it's Helvetica? But I don't see the word Helvetica anywhere on the page. Maybe it's expected that the user will know why Helvetica is the right choice.<p>from /preview/grid : "A collection of classes to build grid based layouts with absolute ease. This is the simplest grid system you'll love to use." This feels weirdly sales-y for documentation.
Well done. I work in a large enterprise and have no design ability. Tired of banging bootstrap together and not quite getting the look you achieved with Flakes. Looking forward to trying this.
Not sure why Bootstrap bloat is a problem if it's just going to be an internal app. I'd rather go with a more familiar, and well known framework, and not have the overhead of learning yet another framework (not to mention others who would maintain or contribute to the internal app would have to pick up this new framework)<p>That being said, I do like the look and feel of Flakes. Also, given that graphs and charts are key to internal business apps, would be awesome if there was some easy charting integration / capability.
I'd called that "lean and clean" instead of "boring". And I wish that more user facing apps would look like that, not just internal ones. Maybe it's just me, but all these flashy things, unnecessary effects, animations only clutters the screen and makes app harder and annoying to use. Functionality and ergonomics is all that usually matters. Well done, I'll give it a try.
The 'consumerisation of the enterprise' is here to stay. Having a USP that is a negation of something beneficial and pleasant in UI pleasantness and that drives adoption is likely only to work against the success of this framework, let alone the narrower only 'internal' market reducing the role of the open source community in its continued development and their passion for it.
What about OpenUI5 for business apps: <a href="https://openui5.hana.ondemand.com/#content/Controls/index.html" rel="nofollow">https://openui5.hana.ondemand.com/#content/Controls/index.ht...</a><p>From my initial tests, it's very clean MVC (a bit verbose). Also the deploy story is not too good... (frontend code ships as a .war). Does anyone have experience with this, good or bad?
I prefer something more feature-rich, using a known framework like Bootstrap. There's a lot more features and examples built in to inexpensive templates for Admin interfaces like SmartAdmin - <a href="https://bootstraphunter.com/smartadmin-product.php" rel="nofollow">https://bootstraphunter.com/smartadmin-product.php</a>
This is a pleasant change. My goto framework for internal apps is Bootstrap (no surprise there) although I actually end up using only a handful of elements. Flakes looks like a good enough collection of elements to cover 95% of my use cases. Definitely going to use this in my next app.<p>Thanks for sharing!
I think it looks sharp. But the monotonality, or lack of contrast within the layouts blends elements together, so I would find it difficult to read and interact with for an extended period of time. It is very cool, I especially like the Grid Forms -- those are so sweet.
Went to this page: <a href="http://getflakes.com/preview/browsing-data.html" rel="nofollow">http://getflakes.com/preview/browsing-data.html</a><p>The 'Next' button on the grid seems to be broken. No javascript error in console. Current stable Chrome, Windows.
There's some nice visuals here but it's hard to see why I should choose to invest my time into learning this rather than something more standard like Bootstrap. And I don't really see how any of this is specifically oriented to internal applications.
I think it's strange that they use Morris.js[1] for their graphs on the main pages, but don't mention it anywhere.<p>[1]<a href="https://morrisjs.github.io/morris.js/" rel="nofollow">https://morrisjs.github.io/morris.js/</a>
Am i missing something, or is there no explanation anywhere on their site of what this actually does at a detailed enough level targeted towards a developer?<p>Update: never mind, found the docs hiding inside the live demo page.
The 'select all' checkbox on <a href="http://getflakes.com/preview/tables.html" rel="nofollow">http://getflakes.com/preview/tables.html</a> has no effect my Chrome.
Just wanted to mention that I work on NimbusFoundry(nimbus foundry.com) which has similar ideas except we focus on auth, storage of data, and permissioning instead of front end. This is so that users can create apps within enterprise environments like Google apps for business easily.