but have obviously never made ...
It begins with the orientation of the screen - and creating layouts that work with different sized screens (devices) without the need to scroll in form view. When upgrading from FM9 to 10 and above, all my layouts required redesign to accommodate the toolbar moving from the left to the top. Took up vertical space, which is always at a premium on vertically challenged computer screens. Okay for ipads - your simply rotate - but try doing that with an iMac.
In list view ensuring that when vertically scrolled, the next batch of records fit neatly into the space - i.e. no part records.
Buttons that don't necessarily do what you intend. Even with labels explaining their function, people click them and are surprised by the result.
Fields in an illogical order. Especially address fields. Oh and e-mails fields where people want to include a number of e-mail addresses, where only one should be included.
As new fields are added to an existing layout knowing when the time is right to go for a complete redesign.
Anything that allows for (unintended) record deletion.
I shall gloss over my own ineptitude...
"Angry Fruit Salad"...I see it over and over again...from folks who "should know better"
Followed by screen clutter...They gave us tab panels for a reason...
Followed by naming of tabs to be intuitive (or lack thereof)
The use of every available color, font, font size and font style in one layout plus a thousand fields splattered around the screen without any obvious order.
Incorrect context (especially when the relationship graph is extensive or complex, even using 'anchor-buoy')
For instance, using the wrong table occurrence when placing a field on a layout.
Or when defining a field calculation, not making sure the table occurrence context of the formula is correct (Usually, that's the base table of the field. Usually, the default is correct. However, I have worked with databases where the "first" table occurrence of a base table is not used as such, whereas if that initial TO still exists, is the default used by FileMaker. Yes, this happens a lot when restructuring a legacy relationship graph to 'anchor-buoy' format).
A vague question (although well meant) deserves a vague answer (well meant):
If your solution needs a manual, then it has UI mistakes.
To be more specific, IMHO the most deadly UI error is the lack of consistency. Which has many ugly faces, like use of color, placement, wording, symbology, modifier keys, etc.
A very good compilation can be found by reading THIS.
clicking into a field placed in a portal and it jumps somewhere else due to cascading triggered triggers.
so a second click for the user is required.
very hard to fix
Reinventing the wheel: Users are often already used to certain UI/UX workflows. Find out what they use. What they are familiar with greatly affect their cognitive load. Do they use Gmail, do they use Outlook, do they use Mail ( OS X ), do they use Excel, Word, Photoshop, InDesign, Chrome, FIrefox, IE, Safari, a lot of iPad/iPhone apps, Android apps, etc...
Example, if they use certain apps on their where swiping a line item left deletes it and swiping right saves it as a favorite...don't create an experience where swiping left saves a record and swiping right deletes it.
Also, don't hijack shortcuts. I used to constantly get Excel spreadsheets from our management team where they would record macros to perform tasks for us. For many sales reps, that's necessary. But the author of the document would use shortcuts for ctrl+a, ctrl+s for macros that would sort, delete, replace data on the visible worksheet. The HUGE problem, is that those macros will run on ANY file you are working on. So if you flip to your MainReportThatYouSpent12HoursOn.xlsm and hit ctrl+s to save the file so you don't lose 12 hours of work...that macro from the file you have in the background that has hijacked the shortcut will now run...and destroy your report. With no undo. ( but at least I'm not bitter about it )
Thanks for the replies. Some good tips. Starting some new projects, so good to have a fresh take.
One of my pet peeves are navigation controls that are different on each layout. They should be consistent on all layouts in function, location, and design.
"Develop from an iPad first view. It then looks extra clean (white space) on desktop & web."
Might be good...but be careful about applying it across the board.
I build dbases that will never conceivably be on an ipad...there is no reason to develop from and iPad first view...
IMO, you should build to fit the intended and reasonably expected usage...plus a little.
yes! and I think that's what many are saying. Those of use that had to move to web and iPad for clients have learned to start that way of thinking for all solutions rather than trying to recreate after the face. Just take the advice of many who had to start over...
On Oct 8, 2015, at 9:25 AM, Eric Twiname wrote
Along the same lines, although I haven't seen this one very recently, are layouts you can get to multiple ways, but which has a "back" button that always goes to the same place.
Not sure if you are agreeing or disagreeing (either is fine )
If the solution can go either way in the future, I totally agree with planning primarily for mobile...folks are used to mobile and having the same "look" is no issue even when stationary.
All the same...if it'll be a cold day *somewhere* when the solution would ever go mobile, then it doesn't make a ton of sense to spend time making it easy to go mobile. That's usually where I live, being an in-house developer with no other "clients".
At the end of the day, I suppose it's really about understanding and applying 'how the solution will be used' and building accordingly...an important consideration on every level, from design, to workflow, to speed considerations.
I think it's partially about how the solution will be used. But also, it's important to factor in what the users are already accustomed to. If they use a lot of mobile apps or web apps, that will affect what they recognize as familiar UI, and expected actions.
I agree with your statement, however years of experience brings out the old adage 'never say never'. Take it how you will.
You are right. The mobile first as a rule is not sensible!
Well...I'm not sure it isn't sensible...I think it likely is pretty sensible...just not the only choice 100% of the time.
If there is a realistic chance that the app will be used on mobile in the next 5 years...I think that planning for it up front is probably a good idea, simply from a time management point of view.
There is no issue using touch-screen controls from a desktop.
If it never goes mobile after all...you really haven't lost anything.
But if it does go mobile (and much of the world is...quickly...) resizing a few things is way easier than a full UI redesign.
All the same, mobile has been banned from where I work...and that won't change anytime soon...so I'm not very concerned about it.
The apps for the sales folks are built with mobile in mind...
At the end of the day, knowing how the app will be used is a key decision point.
If it needs a manual or explanation it is not right.
One big issue I see is many developers putting controls on the left side of an iPad when nearly everyone in the company is right handed. Left side controls are popular on the desktop, but... I did a test once and just watching how users had to try to hold the device with left hand and use the right hand to use controls on the left sides was almost entertaining. The latest stuff I do has a user profile that uses left or right control layouts based on the dominant hand they use. Double the layout work but it is easier on users and speeds up work.
great observation, tom! you can have two "sections" and change the anchors so the "nav" appears where needed. I'm not sure it can be an "option-to-the-user", but perhaps thoughts will come to mind.
beverly, thanks. I take UI/UX pretty seriously as it is the true test of a good solution and a big advantage of FileMaker. Any platform can deal with the data part. Getting that data to be easy to access and use for non tech people in a work environment is what gives it tremendous value.
This could very easily be an option to the user with a a global variable that would simply dictate the L or R layouts to be used via script.
I suppose you could also build both controls onto the layout and just hide one or the other based on the variable.
I did not know anchors could be changed. How does that work?
not scripted or calculated, just manually set. but you say you could have two copies (one to the left, one two the right) and hide based on preference. the anchors can help here too.
I have wondered about this. Can't see myself creating more layouts and complexity at this stage. I might try centring menus based on what you are saying though. Middle ground! FM GO uses this approach I see.
Retrieving data ...