Live data from Hacker News

Show HN: Front-end framework optimized for internal apps

getflakes.com

51–60 of 94 posts

Re: Show HN: Front-end framework optimized for internal apps

#52
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.

Re: Show HN: Front-end framework optimized for internal apps

#53

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 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".

Re: Show HN: Front-end framework optimized for internal apps

#56

I really like gridforms for dense data-entry forms ( http://kumailht.com/gridforms/ ).

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.

Re: Show HN: Front-end framework optimized for internal apps

#58

I really like gridforms for dense data-entry forms ( http://kumailht.com/gridforms/ ).

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…

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.

Re: Show HN: Front-end framework optimized for internal apps

#59
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.

Re: Show HN: Front-end framework optimized for internal apps

#60

Earlier quoted context omitted.

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…

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.

Post reply on HN