Brainstorm: Creative ways within Meteor to design a complex business UI? (layouts / pattern / packages)


Hi boys and girls,

I’d love to chat a bit about doing complex User-Interaces the Meteor way - in particular I’d like to get some ideas on how to design a business-like desktop app (p.e. an SAP-Style ERP System) where a lot of data is connected and has to be made accessable to each other.

Look at this (old-fashioned) mess right here:

For example: this here is a not-too-trivial UseCase called “Create New Bill”:

From the user-perspective: Our user wants to create a new bill and is in the mask “create new bill”.
In our “create new bill” we want to give him this functionality:

  • search&pick an existing customer (offer complex search functions, p.e. phone number, name)
  • create a new customer and assign it to the bill
  • add products
  • change product description of the product master data (he notices that there is an typo in a description)
  • … and so on…

We can already see that having a base-view PLUS 1 modal window available might NOT do it for use.

OK, Meteor-Freaks:

aldeed:autoform - No question, no alternative
aldeed:autoform-select2 for simply use-cases (but is not enough for a complex search-form)


  • Togglable tabs
  • Modal window (it only supports 1 at a time so this kind of sucks)
    The MODAL-WINDOW-TOPIC is giving me some headaches: Having ONE Bootstrap Modal available simply is NOT enough… and managing modals manually gets really complicated… So **what other concepts/pattern/packages are available?
    How about sliding in- and sliding-out data-panels?
    How about offering complex search&pick forms?
    Any ideas on this one?

FlowRouter Breadcrumbs (like or text

Reusable Components
I have spend some time with @mitar’s Blaze Compoments and they really help me a lot with structuring my project. What a great package that is! :thumbsup:

I wonder: What other patterns are available and what packages can we use?


Good question. Also your view on it is interesting. Those interfaces generally are grown over the years. They started with something simple and then people added more- and more buttons.

Can be just fine for an enterprise application. And how it looks generally is based on the tools they received from their framework.

The reason they look so similar and they use all those popup windows for search is generally also because that’s a tool at hand.

The description 1, description 2 and description 3 fields might be a good example of a limitation they had to work around. Might be there was a limit if field size or no newlines were allowed for example.

So maybe don’t make it you target to copy this kind of designs. You will get there during time when you have to add more functionality :wink:


Yeah this is definetly a good point - we DO NOT want to copy this kind of stuff, but still we need some tools in our belt! :smile:

What would be the Meteor way to do this kind of stuff?


Making the forms itself is not very difficult, you described the tools and you could even make your own form handling tool if you need something specific.

I think the most important issue you will encounter is how to structure bigger apps. That’s a general issue with Meteor where no answer if for at this moment. There are many options.

Also you will need to manage some kind of backend ERP like system. That’s where all the dependencies are. That is the most complicated part. I think it’s important to see that there are many systems mostly behind this kind of software.

It consists of many different sub systems which connect together. I think you should be able to make a frontend with Meteor but for the back-end you should first think about that structure.


regarding modals, there is peppelg:bootstrap-3-modal
we are trying to stay out of modal world tho
so in our recent work, all what was normally in modal, just expand inline into site with some toggle button for expand/contract
I would expect it would be default behaviour for all forms, but in these old static times, there was no easy solution and direct DOM manipulation was not very easy, so they generate new window for everything.


Using React for this would a good option as everything becomes an individual component and it becomes easier to manage.


I’ve delivered three considerably large line of business type apps so far. I’m not exactly very happy with any of them in terms of user experience. To be fair/honest, I’ve never actually been exactly happy with any such web facing app, anyways.

The only big problem (in this regard) with any frontend web/css/component framework I think is the lack of “enterprise perspective” Yes the SAP screens there look awful but that’s actually not a baggage from the past and it actually works surprisingly good and robust. You must see people entering data on SAP forms. It’s like a breeze. Up par with desktop data entry.

I think webix and kendo come pretty close. But the thing is, these, especially those based on bootstrap classes, favor visual white space whereas such business forms require density.

I think SAP forms are functionally very correct. Their keyboard/mouse navigation patterns, search modal patterns, niput masking etc make it a breeze to enter data.

They may make good use of some style overhaul, though.

Regarding a forms framework, aldeed:autoform comes very close to a good form framework but it becomes resource intensive once forms begin to grow and reactive validation is not a very good thing because it may end up confusing users about which point in the data entry flow they are.

I don’t know about React, but I think the currently available form frameworks are not very good with nested data structures which is a very important requirement for business apps where there usually are master/detail data entry flows.

I think modals is the easist thing with meteor. Just render a div (with Blaze.renderWithData) that’s positioned fixed/absolute and make it draggable so that multiple modals can be stacked.

Breadcrumbs are couple with routers. But SAP type apps create a trail that’s decoupled with the route, in fact the routes do not make much sense and breadcrum represents the point in the app menu hierarchy rather than the user session trail.

I think we are in good hands in the eusable components departments with blaze components, viewmodel and react alternatives.

Regarding the backend, that’s a whole different topic. I believe reactivity must be limited and a client->server-method-> client paradigm (similar to request/response client/server models) should be favored so that the server can actually become and (from the user perspective) act like the single source of truth.

I think @awatson1978 and Steeve Cannon (etherpos) should have the highest experince in erp-like apps.


Heh. Could talk about this all day long.

California Kids Cancer Comparison is the biggest ERP style app that we’ve been able to open source.

  • The medbook:studies package is a pretty good working example of how we use Autoforms, SimpleSchema, and Blaze Modals together. It’s as good a place as any if you want to see how we’re wiring together CRUD templates, modals, schemas, etc.

  • Select2 is a nice idea in theory, but horrible in practice. It was the first thing to go.

  • We ditched Bootstrap awhile ago in favor of a JSS strategy, and have gotten all sorts of sexy animations and effects because of it. That’s caused us to have to up our game with regard to animation-based UI design. We use the Day Made of Glass Videos as our design vision.

  • As you dive deeper in the UI rabbit hole, and ask yourself ‘how do we implement this ERP style interface using modern programming techniques’, a few design patterns start emerging:

  • I’d highly recommend Schwesinger’s The Form Book if you’re going to dive deep into this domain.

  • Be sure to check out the keybindings on the CKCC demo app. Command+Control+L and Command+Control+R should get you some of the sliding docks that you’re asking about. Actually, Command+Control and just about any key on the keyboard will toggle some animation or another. (Some/most of the animations are experimental; so if the layout gets into a funky state; refresh the browser.)

  • The Form Builder has some nice examples of dynamic layouts, with panes sliding into their respective positions.

  • We’re in the process of writing up a series of architecture documents that will explain the approach in more detail. So, if you hang on for another month or two, we’ll have some flow charts, storyboards, and other relevant design docs to contribute.