Recommended
More Related Content
Similar to UX, Crud and the almighty Enterprise Application
Similar to UX, Crud and the almighty Enterprise Application (20)
Recently uploaded
Recently uploaded (20)
UX, Crud and the almighty Enterprise Application
- 4. Private sector Banking Pharma Public transportation Startups Public employment service
- 11. CRUD DATA
- 12. DATA
- 13. Search DATA
- 14. Search FORM
- 15. Search LIST
- 16. FORM LIST
- 18. FORM LIST
- 20. Enterprise Application “... is computer software used to satisfy the needs of an organization rather than individual users. …”
- 21. “... is computer software used to satisfy the needs of an organization rather than individual users. …” Enterprise Application
- 22. “... is computer software used to satisfy the needs of an organization rather than individual users. …” Enterprise Application
- 23. Enterprise Application “... is computer software used to satisfy the needs of an organization rather than individual users. …”
- 25. UX BUSINESS&
- 26. KNOW BUSINESS
- 27. MODEL BUSINESS
- 29. BOM
- 30. READ
- 37. BORING is GOOD
- 39. How do I STANDARDIZE
- 40. DIVIDE CONQUER&
- 41. DIVIDE CONQUER
- 42. DIVIDE CONQUER&
- 50. CONTEXT Master - Slave
- 53. BUTTONS CRUD
- 54. BUTTONS There can only be ONE
- 57. BUTTONS There can only be ONE
- 58. Say what you do Do what you say &
- 59. LISTS are ...
- 61. LISTS are SIMPLE
- 62. FIRM RIGID
- 63. IRL
- 66. 80 page doc
- 71. DID IT MAKE ME THINK
- 73. Q A&
Editor's Notes
- Hi I’m Steven Verhoest
- I started in 1996 as a webdesigner and I call myself a UI/UX designer. In these +20 year I have done lots of thing.
- I worked on many projects, probably more than I remember
- But mainly on enterprise applications in many fields. I’m going to give you a personal view on...
- On Create, Read update and delete Aka CRUD
- I’ll talk about the importance of crud and its importance in regards to the almighty…Enterprise Application
- Enterprise Application A couple of years ago I was hired as the sole designer in an engineering firm to design the application they were going to build. There was however nothing.
- No analysis, No style guide No corporate identity No rules how to build applications Each team just build something and then they were surprised that their applications were not “visually” aligned. Imagine that no … I had to design it all..
- So wow, I could define everything. But I had to design something that was not defined. I knew nothing. Just a vague idea. It was going to be a huge back-office. Customers, subscriptions, pricing schemes, routing, timetables, payments, whatever you could think about, it was going to be in there. I did work for many years as sole designer in developers centered companies. Had to find my way. Need to become pragmatic. NO BS The only thing I knew, the common ground all enterprise applications have is CRUD.
- In my opinion CRUD is the base of every Enterprise Application. There is no EA without lots of CRUD. So what does CRUD do? Crud is all about data.
- Capturing data. Manipulating data.
- Now how do we actually manipulate data in an interface? How do we get to DATA? Anybody? We search
- We search And to search we use a FORM a search form.
- What is the result of a search ??? It’s a …. LIST
- And in general clicking a row in a list brings us to … anybody … It brings us back to a FORM,
- it could be a detail, it could be to edit. But probably a form with new data
- So when we think about it. What do we need to build an EA?
- FORMS and LISTS Just F&L don’t make The Enterprise Application.
- If an Enterprise A is just forms and list. You just have that, a bunch of screens. A glorified access database, a pumped-up EXCEL-sheet. A bunch of fields with a SAVE button. Then what is it?
- Wikipedia describes an Enterprise A like this ...
- It satisfies the needs of an organization ...
- … rather than the needs of the individual users ...
- WOW It goes without saying, but we, designers have the user in the center, it’s what we do… We have a major conflict of interest here. So as a designer we MUST work in close cooperation with the owners of the Enterprise A, the stakeholders, the project owners, the experts We need to work with the BUSINESS
- We need to work with the BUSINESS
- I cannot emphasize enough on the importance of having a good relationship with the business experts. They know the enterprise...
- ...and it’s imperative that you get a helicopter view of the business if you want to create a great UX for the EA An Enterprise is above all a complex system. We build models to capture complexity.
- The model is needed to capture the mechanics that the software needs to replicate. Any enterprise that builds an application to cover their business will have a model in one form or another. The bigger the enterprise the bigger the model. The model goes by many names, but I’ll use one I encountered many times … It’s the BOM
- The business Object model Your job is to build screens based on the input of the business and the bom. The model will give you an idea of the maturity of the enterprise. A bad model, will give to much room for interpretation. The more mature the model, the easier your job is. A mature model will give common ground, a common language between the business and you. The model will give you the foundation you need to get that helicopter view.
- Who has never seen this kind of drawings? Who has? What name does your company give these models? ….. You need to learn to read these models
- Read the model will give you clues on the amount of screens that are needed. It will give you the FORMS LISTS and how the connect
- It is the blueprint of the of the Enterprise application
- You’ll find the FORMS and their fields
- Some relations between the objects will show the LISTS.
- But more important, when the relations between the objects have a description, it will show you the glue between the screens. How the screens connect to each other
- Back to our Enterprise application An EA is a bunch of Forms and lists An EA is all about DATA An EA is NOT sexy You can even say that it’s boring An EA is BORING
- But hey boring isn’t bad Actually Boring makes an application predictable Boring makes it consistent. Boring is a good thing.
- Making things consistent Making things predictable Is all about standardization To make it boring you need to standardize
- EVERYTHING. The more you standardize, the easier it’s going to be for your user to find his/her way through the application, no matter what the application does.
- How do I standize my applications, I follow a set of rules. First when setting up a screen representing data, I Divide and conquer.
- When showing data there are only 3 important thing: Structure Structure Structure Structure your data visually and clearly. Divide the data so it makes sense. What belongs to what. There are many ways to divide a screen in logical blocks. I for one, loves to use Use basic typography rules to structure my data
- I love whitespace. It makes a form breath. Not everyone is a fan, especially the business. All afraid of scrolling. I need sometimes some persuasion to get them to love whitespace
- So divide and conquer Next there is “the context” of your data. Data is never alone. So make sure you always put your data in its context.
- Losing context confuses the user. It makes the application more error prone. So make sure you keep track of your context
- An example. This is a part of a client at the VDAB. Vlaamse dienst voor …. The Flemish Public employment service When going to the detail of a service
- We keep the context. We still know who it is. Context.
- So make sure you keep track of your context Where there’s Hierarchy in data there is also hierarchy in functions. The things we can do on a screen. Give context to the functionalities.
- Add functions at the level where it makes sense. Where it’s logical Give context to the functionalities. Put it where it belongs.
- An example. Sheet of a client at the VDAB. Vlaamse dienst voor …. The Flemish Public employment service Many functionalities
- Put functionalities in there proper context! And then there’s another type of data that are very common The MASTER-SLAVE screens
- These MASTER SLAVE screens are very common in a Enterprise application They group related data. Watch out when handling these data sets. Use the previous rules in this case. It’s where everything comes together. We have the Divide and conquer, group the sub-data visual When going to detail of a “SLAVE”, make sure you still have context. And Keep the functionalities where they belong Don’t be a “jack of all trades”. Don’t edit it all at once Split functionalities to their counterparts.
- Like in this example I used the divide and conquer And kept the functionalities where they belong
- This is what we have until now. When using these rules your well on your way to build a nice boring application But I have some more things BUTTONS The functionalities I showed until now were not really buttons, they are more navigation objects. When I talk about buttons I refer to those items that persists data.
- Remember CRUD, Buttons are the elements behind the create, update, delete of CRUD With these buttons I use the rule THERE CAN ONLY BE ONE
- I’ll show you an example
- I always define The MAIN button A secondary button And a link button There can only be one and only one main button But there can be more secondary and link buttons But never ever ever ever do this.
- But never ever ever ever do this.
- So buttons, but buttons and navigation have language I’m not a linguist, far from it but I learned one and 2 things and as a UX designer you should Be clear as clear as possible and... Say what you do And Do what you say
- Do this to not confuse your user Be clear In general when you say you are to do on another screen use a verb When it’s persisting something use imperative I must say that for English it is less of an issue, but in Dutch there is. At the VDAB we tend to be sensitive for it “Afwerken” - “Werk af” “Wijzigen” - “wijzig”
- Back to lists Now this is a tricky one. This will always create battles with business. You need to stand your ground here, they will always ask for more data in a list, never for less EXCEL is always behind the corner But a list is a starting point and not an end point
- Never ever ever do this LISTS have to be as simple as possible.
- So beware here, slim them down as much as possible. There will be many battles. The stronger your system is the better you can keep your ground. Be firm
- Be firm But don’t be rigid, Know when to yuild. You won’t win them all. Give them one or two battles ;-) Now let’s finish with where I began, the company where I had to build everything.
- The company was prodata and the project was mobiguider. The back-office for “de lijn”
- I designed a full style guide describing every part of an application that was not there.
- The style guide was more than 80 pages Now more important than that, being afraid that nobody would read the document, let alone implement the way I wanted I also build my own model language, It was based on UML state machines
- I called it a navigation model with every aspect of my style guide in there. Be it abstract The model could be exported to XML and then with a small app I wrote it transformed the model in Balsamiq files
- I left the company 4 years ago and I checked, they still use it yeah To finish of I want to end with what is for me most important I always try to look at everything I do and ask myself