@Alisa, thank you for finding that… where did you download that document from? I cannot find it in my libraries. This has not been properly updated. It has been a long time since 1024 was a standard that we recommend.
Currently our developers are designing browser based screens for desktop use while in 1440 mode.
Support provided it to me - so Epicor IS still recommending 1024 . . . crazy but true.
Without JavaScript? How? Why all the CSS viewport code if the server already has the resolution?
Well then…
- 1440x900 should be the recommended hardware.
- If users are using a window, full screened or windowed, Kinetic should stay at that minimum size and make the users scroll, instead of collapsing screen items and hiding things.
2 Likes
I cannot agree with these 2 points strongly enough. Hiding things in an ERP system is totally unacceptable. The users have no idea what is going on and it leads to so much confusion. They don’t think, oh, I will try to maximize and see if its there, especially since the screens do NOT open maximized in the client. A scrollbar intuitively tells them where to find the info that is off screen.
2 Likes
This is not responsive design. One of the major reasons for going to the web is to expand the number of devices one can use including tablets and phones. Sure, most of us sit at a computer all day but many users of an ERP system are moving about the facility. I want to bring information to where people are. Let users decide what is useful for them to do their job and stop trying to make the perfect page for everyone. The web has learned this lesson but we desktop people haven’t yet.
The way it works now is ALSO not responsive design. Responsive design is adjusting the content layout to the screen dimensions, not just hiding things because the window is smaller than what the developer used.
3 Likes
You are absolutely correct. Moving some navigation items to an overflow is OK IMHO, but content should flow and collapse but not disappear completely. At least for me, vertical scrolling is easier than horizontal scrolling.
Another sit at your desk story, when a previous company implemented MS Teams, we found some users would benefit from headphones/earbuds for audio communication. The IT Manager recommended a list of devices - all wired versions. Didn’t spend much time in a plant… 
1 Like
This is the current document in EpicWeb. I’ve already reported it to Support. CS0003367127. It’s actually referenced the same in the Hardware Sizing Guide as well
The case specifically relates to the User Experience being degraded by hiding things or changing the playing field of what functions work or don’t work based on resolution.
This KB was provide KB0098995 - Edit area on the Kinetic HomePage is grayed out and can’t add widgets at which point I brought to attention the discrepancy with min recommended viewport and what is required to have full function of the menu editor.
This second KB article was supplied by support that is very poorly written, missing images, and probably not any more helpful than the other KB0111613 - Widgets Grayed Out when Editing the Home Page
1 Like
I agree with you, but this is an ERP system, not facebook.
What we have now is not responsive either. It’s a mess is what it is.
I’d be happy to have it truly responsive, and resize properly, with clear indicators of why and what is visible and not visible. Responsive design should also be intuitive design. And it’s not.
Right now, it “appears” as if the screen is just broken sometimes. If I have to explain it. It “IS” broken.
I know they are trying to address it, but instead of this land of broken dreams we are in now, it should just enforce a minimum size until they get their act together.
/rant off 
4 Likes
Again, I completely agree. I just don’t want to see screens designed for a single size, or for experts, or for beginners, or whatever single attribute that’s deemed important by one person or another. Give control back to the users who use the system whether it’s Twitter, Facebook, or an ERP system.
It’s Christmas and all I want is a UX miracle.
1 Like
A pipe dream. You been hittin’ the nog a bit early.
3 Likes
1 Like
in the days of FHD/4K/8K… we’re talking 1024x768
none of our users, even shop floor are running less than FHD… because it’s 2022 
something like 5% of our workforce are on 4k screens, but those guys are running zillions of things all over the joint Epicor fullscreen on that would be hilarious 
1 Like
Desktop Users:
1680 x 1050
Shop Floor: (Mainly due to n-computes, pi’s, mini itx)
1280 x 1024
Power Users:
1920 x 1080
However most of the company runs on Citrix or RDS which may run a lower resolution, if the Window is being streamed. Citrix makes it feel as if the app you are running is Native to Windows, you dont actually RDP into a Server, it crops out the application.
Other Notes:
Magnification for Power Users is usually set at 100% while Desktop Users sometimes favor 125%.
It would be interesting to see how Kinetic renders on an Ultra Wide Monitor, when its Maximized. They are gaining momentum slowly for Power Users. I dislike them.
Also note the Client opens up in 1180 x something. Wouldnt be too bad to update the default height and width a bit.
Im going to make an assumption that Epicor wasn’t targeting Responsiveness for the sake of Responsiveness but instead, they are trying to make their ERP work with Tablets & Phones. I wish they did a study on how many people would actually use something other than MES on a Tablet or Phone. The whole assumption thing hasn’t helped with Epicor Social or EVA.
Other’s like Facebook, Google Maps and so on… Have a Responsive Web App, but if you want a true Mobile or Tablet Experience, you download their App from the App Store. They have even different flavors of their Apps such as Lite Editions (to consume less memory etc).
There was a time everyone would slap a Web Frame around the PWA App and call it goods. But people are returning to making native applications for mobile devices. Including getting rid of PhoneGap & Cordova in favor of Swift & Kotlin. They hire entire teams, for it.
Maybe Epicor should rethink a bit and maybe make the Mobile Experience a seperate App and not clutter it with Erp. It could even be /Apps/Mobile/home. Now they have bundled Mobile, Data Collection & ERP all into /Apps/Erp. I am not sure how it will pan out, maybe a split idea which they once headed towards, is a better idea. Im just old.
. . .
I would never use Excel on my Phone. I even dislike the Office 365 Web Version. That is why Google Sheets, will never become mainstream, id rather use LibreOffice.
– Old Guy from 87
2 Likes
“Epicor Social or EVA”
Are these now in the “Seemed like a good idea at the time.” wing of the Epicor museum?
A museum would imply they let it go… :Wink
Yep, if you try to force it all into one, both experiences will suffer.
There are issues with native apps too. One is customization: you won’t have any or it will be very limited. The Kinetic Wireless Warehouse, CRM, Time and Expense apps use this model. The UI is very different, and some customizations can only be done through professional services if they can be done at all. Another issue is installation and updating. Every device must be touched, and it can take time to push updates because of the vetting processes of Google and Apple.
There is newcomer to cross-platform native development and that’s Microsoft’s .NET MAUI.
Microsoft says:
.NET MAUI is for developers who want to:
- Write cross-platform apps in XAML and C#, from a single shared code-base in Visual Studio.
- Share UI layout and design across platforms.
- Share code, tests, and business logic across platforms.
.NET MAUI apps are native apps that are downloaded from the App Store and Google Play or installed natively on MacOS or Windows. .NET MAUI shares all the disadvantages of native apps but at least it has a common codebase.
I think the solution that falls in-between native and first gen web-apps will be the use of Web Components and WebAssembly. Web Components give the developer a way to build the UI in well-defined components that can be embedded into other components. Consider a part inventory component: it may appear in Order Entry, Part Tracker, Issue Material, etc. and it’s all the same code instead of writing that UI for every screen that requires inventory information. WebAssembly allows operations to push updates through the browser like a webapp but have it run at near native speeds - even offline. And there are far more HTML developers out there than Kotlin or Swift.
This reminds me of a quote:
“I’ve come up with a set of rules that describe our reactions to technologies:
Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
Anything invented after you’re thirty-five is against the natural order of things.”
– Douglas Adams
You’re not old. You’re right on time!
– Older Guy from '63
1 Like