Open agritheory opened 1 year ago
Splitting some of the workflows here into separate tickets by the user's responsibility.
Shipping and Receiving
Stocking
Manufacturing
There are three general patterns for directing the user about what actions need to be taken. These concepts are valuable for building the listview(s) for each core responsibility of BEAM. They can be further filtered by warehouse and/or workstation.
The status and ordering/ prioritizing of these actions from internal activities (2 and 3) reminds me of one of the more interesting use cases for Redis: a leaderboard. They've built a Django-based example with a frontend. I think this would be a reasonable way to communicate to the various users what needs to be done and where. This would probably be best implemented by updating the leaderboard from enqueued dochooks on Bin, Sales Order and Material Request. The only state that would need to be managed for the document would be when something is manually reprioritized, which can be a regular whitelisted function that save the new ordered value and pushes to the clients. If one of the "action signals" gets a "start" action from the user, that value can also be updated and the pushed to the subscribers of the leaderboard. The client side of the leaderboard can be filter out "active" documents.
@agritheory Here is a link to the wireframe in Figma. If that does not work, I also have a PDF attached.
BEAM Work Station Wireframe.pdf
Let me know if this is close to what we discussed or if I misinterpreted. The idea here is that work orders open the split layout for job cards and work timers. Clicking job cards will bring up the job instructions as well as retain the timer.
I see the design is mostly focused on work order layout. Would like to also see the design around inventory movement flows. Also @agritheory , should we add a slight shadow on the cards? I would like to see what that looks like,
@hpema Wireframes don't typically have a box shadow or other styling, it's more of a "locating" reference. The other point about this being about the Work Order flow is a good one. Curt and I didn't cover that in the brief we had about this, but we probably want to add it. It is possible but not always (usually?) appropriate to let the Work Order drive the material transfer and consumption. Once we have a way to add that, I think we'll also want to run through the spec/outline and think about how each step goes wrong and we recover from it.
@crabinak I really like the thoughtfulness and clarity of the pages 3 and 4 of the design, it's a nice improvement on what I had imagined. The list view I have a feeling we'll change but I don't know exactly how yet - likely some filters - but I think it will be more of a refinement once we have have an interface that we can manipulate. The login page will probably get a message than tells operators they'll be able to scan in if that's enabled, but is otherwise the kind of straightforward design we're looking for.
Actions
Components already in progress here