paul@researchware.com wrote: ↑Sat Aug 17, 2024 1:38 pm
Ideally, some of people who use the free app, see it was made with Livecode, and seek to have more apps built using Livecode.
That can cut both ways.
"Everyone can code!" includes people with no UX background and/or budget.
Remember one of the reasons Steve killed HyperCard:
HyperCard stacks smell funny.
Mac users have an innate sense of “Mac-like”; most Mac users can determine whether a particular software package is Mac-like within 60 seconds of launching it and poking around. And HyperCard stacks, at least the ones I encountered during HyperCard’s heyday in the early 90’s, never felt even close to Mac-like. It always felt like HyperCard was its own little GUI universe running within the Mac OS (even though we didn’t call it “Mac OS” back then). Stacks felt and looked consistent with other stacks, but never felt, looked, or acted like other Macintosh apps.
https://daringfireball.net/2002/08/why_hypercard_failed
I frequently disagree with Gruber, but this one isn't one of his apologetics for Apple's missteps; it's simple observation, reflective of Jobs' high priority on good design.
Of course we've all seen really attractive apps made with HC back in the day, and many more so with LC since it goes so far beyond HC's limitations.
But good design doesn't just happen. Like anything else, it takes focused study with practice over time. Even the smartest dev in the world won't be a good designer without splitting their time between coding and design.
Many commercial apps have weak spots, but if the budget is zero weak spots multiply.
Let's explore a user journey, a quest to learn about LiveCode in the world's most-used app store, Google Play.
Searching for "LiveCode" brings up many things, nearly all related to the generic use of the word rather than the LC we know and love.
But there is one app that shows up, and thankfully at the top of the search results.
It's not from the company, though. The demos the company used to publish fell out of the app store long ago.
This is a LiveCode Dictionary from a third party who no doubt means well and I appreciate the effort to make the Dictionary available for mobile (LC Ltd's web UI for the Dictionary doesn't work on mobile well at all). But it's missing fit-and-finish.
We could discuss the font size bigger than it needs to be so more entries are clipped than would be if a more common text size were used, or subtleties line control separator lines darker than we commonly see, or the highlight color unlike any highlight I'm accustomed to from other apps.
Let's see how it looks on a screen with dimensions different from what the developer happened to be using when he made it:
Go ahead, click it to see it full size. It's not responsive, so rather than reformating to make good use of the screen as we see with other apps, this just stretches it. And because the ratio is different, the already-confusingly-large UI elements are also distorted, stretched more on one axis than the other.
It's possible to use different options if you've already decided to avoid responsive design and go for stretching, which would at least prevent the distortion. But the designer didn't. And even if they did, the result would be mystifying unused space at the edges of the layout, things nothing else on their device does.
Responsive design requires care and feeding; it can be done in LC, but like any good design it takes rolling up one's sleeves, studying the opportunity carefully, and implementing with diligence. That's least likely to happen with no budget.
Then there's interaction.
Using the app matches expectations for fit-and-finish established by the UI. Compared to any other app on my devices, this feels slow and awkward, from list scrolling to highlight delay. And your may notice times when the scrollbar is briefly visible and then disappears during card load.
Again, I'm grateful for what is AFAIK the only mobile-usable LC Dictionary around, and I appreciate the developer's effort in delivering it.
Folkware is a lot of what people do with xTalks, scratching an itch easily and enjoyably. And LC makes folkware easier than anything before it.
.
But other people's folkware is rarely the sort of thing an ambitious company wants to build their branding around.
See also what a new user finds going through the sample stacks and tools in the in-app repository called by various names (an issue in itself), aka "Sample Stacks". Oh my. Everything there was uploaded with good intention, and much of it useful. But a lot of it hasn't been touched in years, has no licensing info to inform how it can be used, and looked like what it is, folkware.
Compare that with the repositories for systems like WordPress, Drupal, or Nextcloud.
And the window itself has never even sorted the results in any discernible way, giving the impression of folkware as community culture.
At least the branding value of things under LC's control can potentially be improved. And although left fallow for more than a decade, I would imagine the UI enhancements in the new product will offer a better user experience for finding add-ons and examples.
But other people's apps are outside the control of the company.
Some of those will make Kevin & Co proud. Others not so much.
A virtual dice roll determines whether a potential prospect's first impression of what LC can do well be a studiously-crafted beautiful experience, or folkware.
The required copyright notice has always been welcome and even necessary. We list the things our work depends on, including media assets, engine, DB, etc.
The logo requirement may be a good thing, or it may sometimes backfire. Can't say, no one has a Magic 8-ball.
But since the company branding will be most prominent in the apps with the least UX awareness and budget, at very least I trust we can agree it's not without some risk to the company.
Probably a small line at the bottom of the screen, something fairly unobtrusive and not taking up too much space."
