I normally give thumbs up for most videos I watch on RU-vid to honour the RU-vidr's time on putting video together (if you ever done any video editing, however small, you know how long it takes and you start respecting others more for it). This video series, though, definitely deserves my Like (and a comment) for the great content they put up for us. Well done, chaps!
For the gallery, if you put in select(parent) for the objects then put in 'on select' of the gallery the navigate code, you don't need to put in a button.
@7:27 While you're in the neighborhood of adding an on select to the button, it's good to add the gallery item text to the accessibility text of the button.
Just a pointer on the dont break user expectations and having the whole gallery clickable, the gallery its self has a on select property, so there's no need to include a transparent button. If your worried about having dead zones where labels are placed etc, you just need to add Select(Parent) to the labels on select property and the on select event will fire for the gallery. If you are including the button for its on hover pointer change behavior, consider using the pop or push transition, though like here if its for a mobile experience a hover state doesn't need to be included. Cheers
I opened the video and thought 'Wait, did Joshua Weissman leave the kitchen and works in IT now?' ...and then it turns out that the specialist's name is Josh. There are no coincidences, just signs. I love the video, really makes you think of all the possible simplifications for your app.
Wow wasn’t expecting much at this, but this is a really great video and explanation and reasoning on each change was great. Made me look at some apps and been like dang… I could really make that looks way better.
Version numbers on canvas apps are important if you are updating often / testing - canvas apps tend to cache and this is currently the only way in an app to know you are using the latest version via a web page - mobile app covers this, but not web pages. Main use case is - 'hey I have a problem in the app', cool we've updated the app to v2, the user needs to refresh their web browser until the cache updates. Otherwise - thanks for the tips.
Richard, great point and that is a valid use case for including a version number. In our scenario, the need simply was not as important as the ability to use the real-estate for other content. As an alternative, and if we really need the version number to help troubleshoot a user's issue, in any environment (dev/test/prod), we could simply create an option to navigate to an "about" screen from the main landing screen, where we could display any information we need to about the app.
@@staceymundy4117 - if you have published an app to desktops - so played in the browser not app - then you update and publish that app for your users, the browser will not actively replace the app with the new version. So you could have many people using an older instance of your app - power apps has gotten better at encouraging the end user to refresh their browser to clear the cache of the app. But if you are trying to support an app that is getting updated - its a good way to confirm with your end users that they are using the most recent instance of the app. As PowerApps are low code - they do tend to get updated a bit as users supply feedback or processes become better known - so the probability of an app being published several times is high. Hope this helps answer the question
The only reason I keep version numbers on the splash or welcome screen is to make sure the app is opening to the latest version since PowerApps tends to cache the last version it opened. Later, I've added a version checker at startup to make sure the app is showing the latest version, and if not, then it tells the user to Refresh the browser until the correct version is showing before allowing the user to continue.
As with all things, consider your user. If you have a legitimate use case for keeping a version number, particularly on a splash screen which is dismissed and doesn’t come back, you can always keep it. if your user needs it, you can keep it. just keep in mind the average user doesn’t need or care about a version number, and if you’re trying to find where you can save space and simplify your experience, that version number is low hanging fruit to be picked. in our example, the version number provided no value and got in the way. Good design is often not including all the detail you can, it’s stripping away all the detail you don’t need. if you need it, keep it. thanks for your input!
I, too, hate scrollbars and ALWAYS turn that option off. I usually leave the "show navigation" option on since that provides (when needed) a visual cue that there is more content to be seen.
I'm all for using icons where they make sense, and try to use the least obtrusive ones I can. You can also leverage the "padding" to give users a larger "touchable area" without a cartoonishly huge icon. Finally, expect some pushback from users who don't "get" icons. I built an app used by faculty for entering grades and had the ubiquitous floppy disk icon as the save button, located at both the top and bottom of the form. Sadly, some instructors "couldn't find" that or "didn't know" what it meant (they've only used it to save Word and Excel files for 25+ years, after all). I was forced to replace the disk icon with a button labeled "SAVE".
@@BulbDigital I've often wondered what icon would better/more intuitively mean "save", but keep coming back to that damn floppy! I mean, it's still used in just about every Microsoft app, even though you'd be hard-pressed to even find a computer with a floppy drive these days.
Hey I just wanted to pop in and say - I loved this video BUT the part about adding a button into the gallery to make the whole thing clickable wasn't necessary! You can actually select the top gallery item to edit it, and then instead of clicking any controls inside the gallery and setting their "On Select" property (like you did originally with the right chevron), you just use the "On Select" property of the top gallery item itself! No need for the button or any of that and it works identically. Just wanted to add that!
Hey Max, they're linked in the description! But here's a few of our favorites from him: www.bulb.digital/blog/building-a-power-app-with-a-ux-designer www.bulb.digital/blog/the-power-of-using-color-psychology-for-your-users
For the part of removing text where you have familiar icons, does this impact on accessibly needs? Is the text needed for the accessibility requirements?
Accessibility is a sliding scale and some rules aren't completely rigid, so as in all design, one should consider their audience. Some icons are very well known and need to explanation. Others are niche and need a label. A heart or a thumbs up icon is widely known to mean "like" or "favorite" for example, while an X or a trash can is widely known to mean "close" "delete" or "remove." It's safe enough to use those without a label. If it is not obvious what the icon means, err on the side of labeling when possible. Additionally, consider if your app is being created to be accessible for users with limited visibility or who use a screen reader. For these users, use Alt Tags and Aria Labels to make it clear what the component does. This is standard practice for custom development, but in canvas apps, the burden is on you. If your product is for a general audience, cast the widest accessibility net possible. If your product is for you and 5 people on your team and nobody has extra accessibility needs, it may be safe to cut corners.
