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).
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).
Agreed, was coming in here to comment on as much. I don't think anything on the demos really stood out quite as much as the grid forms does. It's closer to what people who might be replacing a paper form would probably like.
Whenever I'm designing a system that is replacing paper, though it's been a long while. I find it best to start with as close to the paper version as practical. There's a lot to be said for making something that is familiar.
I don't like them at all. Yes, they look pretty, but it's an emulation of the worst aspects of paper forms. The grid-style form is my least-favourite paper form and I frequently find it confusing and difficult to fill out such forms correctly. Perhaps this is because the linear flow of the form is awkwardly two-dimensional, or perhaps because for anything beyond a trivial example, the layout becomes unnatural as the size of the fields don't usually lend themselves to a logical and human-friendly structured layout.
Perhaps it's because the grid style form ignores the importance of whitespace in clear and understandable design. Here's a good test: hold the form upside down and see if you can still tell it's structure at a glance, or hold it at the other side of the room and try the same thing.
Be that as it may, this is exactly the type of form I routinely see people filling out on 80s-era WYSE terminals at airports, rental car agencies, the DMV, hardware stores, and so on. It seems like a lot non-tech people find them fairly easy to get the hang of.
What evidence do you have that people find it easy? My experience with such forms is that people make mistakes constantly. Just because awful forms are common doesn't make them easy. I'd argue that there are many easier styles of form.
Old terminals were fairly space-constrained so I can understand why this choice was made, but modern computers with their high-res screens do not have this restriction, e.g the iPhone has a full keyboard instead of a number pad with letters on, like feature phones had, because they had the space to do so.
Having worked in places where AS/400 terminals where the norm I'd argue that "non-tech people" don't so much as get the hang of it, as rote learn the system and then moment they step out what they have learnt fail miserably to recover. I've experienced push-back on updates to programs that take a five step process back to one or two simply because the person actually using the software didn't understand what typing the commands did and they weren't will to learn the new method.
"With grid forms, lengthy forms can easily fit above the fold. Which means less scrolling. "
Seems like a bad idea to me whenever designs attempt to "Fit stuff above the fold". Scrolling is a lot better, and I think it's better to present users with a portion of the information at a time and allow them to progress through a long form in a linear fashion. Vertical scrolling > horizontal progression.
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?
Life can look good all over. Don't succumb to this "business is serious and should therefore be dull and boring" stuff.
I think they're going for a different kind of boring than what you're implying. It doesn't have fancy animations and flashy colors like Bootstrap and Foundation. It's simple, clean, fast and straight to the point, which is something valuable in an internal tool.
I somewhat agree, in a previous job, one of the products I supported was Sharepoint. Which when you have the Document Management features, work flows, and Infopath forms is a really powerful tool. But sharepoint had a reputation on campus of being annoying and hard to use, and I think a lot of that came from the technical team that originally implemented it got somethings wrong to start with. But those of us in the customer service departments, who were tasked with building services for our customers on top of sharepoint, focused to much on making it technically functional and not functional and easy to use from a user perspective. I'd say if some of the UI bits in our sharepoint services looked more like this and less like what we provided, then Sharepoint would have been a much eaiser sale. It would also have probably helped the resentment from users when we told them that "No, because of the type of information this is, we can't put it in google drive or Google Forms".
That's not why people make boring business applications. It's because they've decided that making it pretty does not add enough value to justify the costs.
In my opinion, the design importance grows with the number of users.
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...
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. :)
I wish you guys luck, and I'll give it a shot the first chance I get.
I work at a very large company and it's the same way. We have a team dedicated to keeping internal apps within certain stylistic and functional guidelines but the overall landscape is still an absolute clusterfuck. Some apps are built with bootstrap, some with pure, some with no styling whatsoever, different hexes for our company's primary color... you name it. Fragmented as all hell.
It's amazing in an "Agile" world, we still feel like we need to "configure" basic design concepts.
For internal apps: Structure could be one theme on one CSS framework. So much time is wasted on "design" (picking colors, lining things up) by people who don't know anything about design.
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.
I also like your search & filters design. I did something like this just last week, but I like yours better. ;-)
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.
I think colours for names of buttons are OK. I hate having to jump between CSS frameworks and trying to remember what the correct class is - danger? Warning? Error? I know what I want is red, and any time I want to change the class of a button or message/alert your core intent is to change the colour - so you might as well skip that abstraction IMO.
I think this is one area where we're going to see some changes even in the enterprise sector. Your average data-grids are pretty familiar to those used to working with spreadsheets, but pretty much everyone is used to rich list views, who also have the benefit of being a bit more responsive (not as good for editing data, though. Although with those gridforms, I do wonder...)
Granted, one screen isn't as heavy with data, but if you're trying to survey that much at once, you'd probably benefit from richer tooling anyways. I'd almost bet that a design that degrades gracefull from data grids to list views will have users resizing their browsers or picking portrait mode to get out of that.
"It goes away with custom fonts" should be "It does away..."
Other than that, pretty cool! There may be a space for this...
Reminds me a bit of http://platform.qbix.com which we built to power social apps (on all devices).
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.
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.
This framework stands in contrast to that, making things dull and boring. What caused you to go down this path?
The way it is built is just perfect to get used to automation of hands. You have the feeling right away that you can use "tab" and "space" to change/fill/move things in those.
Putting more fancy things and making it not "boring" is not an easy job and most of the time fails i think.
"make users feel more at home" will lead users to be focusing less time on the actual task and more time on the tool, isn't it ?
Apart from what this framework does (didn't have time to play much), I congratulate the UX guys on this project for choosing this kind of design and behaviour.
They could have totally another idea maybe for going this path but i love it.
The research shows that there should be a greater convergence because of the cognitive dissonance that occurs otherwise. It is an inarguable fact that people are using software in all aspects of their lives - to have a simplified, straightforward experience in one instance and not the other is a huge source of frustration. I'm not trying to insinuate that making things "not boring" and simplifying is in any way easy. There are plenty of consumer apps that get this totally wrong.
As far as "making them feel more at home" - the more comfortable a user is with an application, the less likely they are to make mistakes. The less mistakes, the more efficiency. The more efficiency, the either:
A) less time spent in the application (for ad-hoc, or get in and get out applications - a common staple) or
B) more tasks accomplished (for bread-and-butter, run the business, 24/7/365 applications)
I want to be clear - I think that what has been built is an excellent job wrt technical implementation.
However, the driving design justification seems wholly contrary to the direction the industry is (trying) to move toward.
> to have a simplified, straightforward experience in one instance and not the other is a huge source of frustration
I fail to see how "simplified" and "bland" relate to each other here in opposing ways. Leaflets to join a gym and tax forms don't really have to share the same design goals, and anything beyond a landing page on the "home" interwebs tends to gravitate towards a more unified, "boring" appearance, too (standard desktop GUIs for the longest time, facebook, almost anything by Google -- or, well, this site).
It would seem that having less colorful, unique splashes would actually run contrary to that, culminating in the abominations we've seen done with Flash in the past (or game GUIs, "unique" and/or cross-platform mobile app). Or the dreaded skeuomorphims we're just growing out of.
Could you give any examples of common webapps that would be the right way to approach e.g. a corporate CRM?
From my experience I disagree. Simpler and well known are more welcome in the enterprise and business in general. As an example consider the protests raised about the Office 2007 ribbon. An internal application cannot afford that type of resistance.
If you had said simpler and more efficient interfaces I would have agreed. Current ERP and CRM applications try to put too much in front of the user at one time. It's better to have micro-applications that match a particular function. This looks like a good idea for that.
I think you misunderstood my post. Everything I've seen does push for simplicity. But simplicity doesn't manifest itself here... datagrids are not simple, no matter how clean the lines are. Nor are forms without inherent rules about use and context. Data saturation and semantic satiation are both immense problems in the enterprise.
My first assignment at my current employer was a short-term, fixed-price project where we had to create a rather boring internal web application that just showed some tables and sent off some pre-made requests to certain endpoints. The UX wasn't high on the priority list, and TBH I wish I had something like this back then, since we had to build our own, then send it off to some cheap designer that came back with shudder light blue gradients. I'd totally go for straight and sleek (and boring) like this project next time.
Never mind that if "boring" isn't the wanted option, the alternative is probably pretty much dominated by corporate identity anyways, where a blank slate is better than some involved design (e.g. gradients, desktop-like 3D look or material design).
extjs isn't so bad.. My only complaints would be all the themes look a bit dated (and squashed on a large display), and I don't like OO paradigms in JS so much and ext is really heavy OO.
I'm generally putting extjs in the swing/MFC/Qt corner, no the angular/dojo/react/etc one, and yes, compared to that in a client/server setup it's not that bad -- at least it suggest a more sane communication setup and is only godawful when it comes to deploying, not outright hostile.
But quite often, some corporations would've fared better keeping their old mainframe terminal apps. With mobile apps, both setups don't really fare too well, although with the recent influx of Windows tablets and styluses, I fear that we could be regressing to shoddy Visual Basic-ish apps with homegrown comm/sync protocols again.
as much as i'd like to say the opposite, it's not nearly as progressive as it should be. There are tons and tons of places who are actively regressing.
How can something be both compelling and at home/comfortable? If you're using the definition of compelling that you appear to be, they're concepts on opposite sides of the same spectrum.
This framework stands in contrast to that, making things dull and boring.
Dull and boring sounds UI to me exactly like at home and comfortable. Compelling sounds like the day to day trend hopping that we see all the time. The frantic activity means it can pick up usability and interaction improvements at a faster clip, but that's a byproduct.
But the entire reason for this conversation could have little to do with Flakes' decisions and be more reflective of the way design will overloads existing words with new vague meanings and create statements that are illegible to people not versed in the existing narrative.
"Compelling" refers to aesthetics and feeling of reward when using the application - "This is an attractive application that makes me feel good when i use it", while "at home & comfortable" means supporting the perpetual novice, allowing easy correction of errors, and lessening complexity - "I can make changes confidently without fear of fucking up because I know what all of these controls do and how they work." The two ideas are most certainly not at odds with each other. To put it bluntly, this framework does neither. It's a plain "business skin" on some well-worn but generally unusable interaction patterns, as I mentioned in an earlier comment.
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.
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.
One thing that I noticed immediately was the UX associated with the hamburger menu.
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.
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. http://kumailht.com/
Way to go, great looking stuff.
I guess it’d be good if the website mentions a bit more what are the differences with and advantages over Bootstrap. I’ve never used Bootstrap for public facing app because I find its look too bland, but I love it for internal apps. IMHO it doesn’t exaggerate at all on the level of ‘glitz’ (one of the arguments of the OP against contemporary frameworks).
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.
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...
I'm thinking about it from the perspective of an ISV that wants to deliver a app with a web interface that is run on in-house servers. Although we could probably just target the capabilities of IE (which does support an early version of the CSS Grid spec) and be done with it...
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.
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.
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.
One man's "forward looking" is another man's "swept up in the latest trends." This framework seems to be pushing back against trends on the design front, so unsurprising it's pushing back on trends in the architecture front as well.
/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.
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)
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.
Bootstrap bloat has little to do with it, looking at the docs. This gives you a bunch of components for specific data views; Bootstrap is far more general, requiring you to create your own components out of Bootstrap's lower-level CSS. It's a specifically geared framework vs a general one.
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.
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'm doing a lot of SAP/OpenUI5 development at the moment and performance seems good. I believe the .war is only needed as a one off if you need to deploy the UI5 libs to a Java server? I'm deploying to SAP systems which already host the libraries so I haven't had that issue. One click deploying from Eclipse is built into the UI5 plugin.
UI5 obviously has the weight of SAP behind it (be that for good or bad!) and new releases seem pretty frequent. For developing web apps to consume SAP data at least it seems the obvious choice (it's very much geared towards consuming oData which SAP Gateway provides).
It's relatively clean, but a bit more klunky feeling. It also seems REALLY sluggish... Not sure if this is typical, but it really doesn't feel nice.
I'm also not a huge fan of enterprisey software development.. SAP and most Java projects make me pull my hair out just getting an environment for development setup.
Yeah the other day was my first day with Java and Eclipse and I was close to pulling my hair out (coming from python and vim). Ultimately it's just a different set of batteries but the depth/weight of the stack seems insane---the expression 'house of cards' comes to mind...
Still OpenUI5 is just js files in the end, so hopefully entreprisey people can't mess it up too 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 - https://bootstraphunter.com/smartadmin-product.php
Great point. From perspective of someone deciding between using bootstrap themes vs flakes the decision would be based on whether you want bootstrap or not. What I don't get is why would you NOT use bootstrap or material design and pick something like getflakes? The justification that it's for internal apps - apps which don't have proper budget allocations, need to be done quickly with usability short cuts? I guess that does happen a lot for internal apps. But why would you not build getflakes using bootstrap or foundation?
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.
Why single out the SASS version? If you compile LESS files you have the same option. I also think Bootstrap has a form on its website which compiles the CSS with the components you want, without having to install/run a preprocessor.
I've always used the Less version myself as a base for customization... lately, I'll npm it in as a requirement... copy out the bootstrap.less and variables.less into my project, update the references and work from there. It's relatively straight forward to do so... from there, I can comment out the parts I don't use. variables.less is mainly copied as a reference point... In my app.less, I include the bootstrap variables, then my own variables, then the rest of bootstrap, then my application less files.
At this point sass doesn't really offer much over less (other than a slightly stronger presence in the design community). I'm using node mostly, which fits in better for me, and makes less a better/tighter fit.
For better or worse, being able to bring in less, react and the like combined with SPDY/HTTP2 will bring some interesting development as things progress. Right now transpiling ES6/7 stuff to ES5 is probably the biggest bottleneck in terms of serving applications closer to as-is.
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.
Yep. Looks like the only thing with any functionality attached is the search. Which is funny because with the search at the top of the page I could see how it would lead one to believe that the rest of the buttons might have functionality attached to them as well.
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.
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?
Update: never mind, found the docs hiding inside the live demo page.
It makes sense if you've ever had to work on internal facing apps, like an admin panel. You wouldn't want the overhead and clutter of something like bootstrap which'd be overkill (albeit you can customize it to be minimal).
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.
Very cool - I like your idea to store all of the data using a Google Drive realtime document. But I'm not sure how you are able to handle authentication and permissions, e.g. limiting a field/model to only be visible to certain users. AFAIK read access to a document in Drive is all-or-nothing, and there doesn't seem to be a way to let a user only view a portion of the document. Are you only enforcing the access control in the client-side logic? If so, that's not even remotely secure....
By permission, we mean that each team's data is hosted on a single document, and when you add a member, they can see both the data in the app and also binary files associated with that data. We don't try to do differing levels of permissions not supported by google
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).
Watching this project now!