Skip to main content

Hey everyone, 

Moving a conversation that started between @gstager and I over on a different question to allow it to live on its own and encourage more to converse. The original thread can be found here:


What kicked it off was to accomplish the request the idea of using an aria selector to hide a navigation element which I had a knee jerk reaction worried about different types of users interacting with the page, but more generally what I see a lot on here of just how to hide things without thinking through the full repercussions to different end users. The beginning post that really started it was me explaining why I had that reaction here:

 

More just using an aria selector to hide things, since the goal of aria selectors is to help navigation. In general I have a hard time with hiding entire navigation sections without being able to adjust the page completely as it does tend to leave gaps and loopholes for how people navigate through non-visual based methods.

In docebo’s particular case I also play the balance card of, if you are offering the mobile experience, the css mod’s from style sheets don’t apply there so you then have two very different navigation experiences on browser vs. app which is generally not great.

I get it, the way the platform is architected, there’s not a lot of choice sometimes, but I also think a lot of people try to solve problems by just hiding without thinking through the complete ramifications, not saying this particular case, just in general it is a pretty common question on here “how do I hide x” and css display:none works, but should be the exception and not the rule in my mind. I try to stick to enhancements using these types of things, so that they follow graceful degradation ideals, and if something doesn’t load right because no one customized it at its viewport or interaction model, or whatever, the built in still works as a fallback which has a team of people testing such things.

Lastly, when getting that specific, ties you to constant breakage/updates of the platform which gets tricky and can cause “emergencies” during updates since we don’t control the platform changes underlying.

It’s the ol’ spiderman thing, with great power comes great responsibility, and sometimes just knowing how to do something is not as important as knowing whether you should or shouldn’t do it.”

 

So in the spirit of discussion, what do others feel about managing the want to customize versus user consistent experience versus other things? How do you decide what is worth the maintenance and testing cost of customizing versus dealing with limitations? What user personas/devices do you take into account when making changes?

Definitely go read through the thread from above too as we chatted a bit!


 

We manage several client instances and some that have multiple tenants so we tend to try and limit the amount of CSS changes simply due to the potential effects on other users as well trying to keep customizing to a minimum wherever possible. All changes whether at the global level or at the sub domain level are logged and maintained outside Docebo in case they disappear with an update, etc. Stability of CSS changes are never guaranteed so the more you have the more you need to check, test, modify, etc. etc. each time release hits.


@lrnlab love the external tracking, I try hard to keep those who potentially touch it to keep a backup doc in our teams site up to date but most ignore, so it’s just me. I’ve been debating trying to make a SharePoint list that maintains items independently and have a flow output it all, trying to keep things grouped and more user friendly than just the word doc, ideally the field could be updated via api and then I could have that flow just update directly, but easy enough to copy and paste. 
Are you doing anything special for that backup? How about notes within the doc? Any team conventions/strategies to keep it all organized?


@Bfarkas not particularly...I make sure to comment out the reason for the CSS addition and whenever I make changes I maintain a TXT file that I copy the changes to. always good to have a back up & record of all the changes cause I’ve seen some code disappear after an update and sometimes code that no longer works, etc. + I apply the same code across a few client instances so it’s easier to pull it from a “master file”


Gotcha, one of the things I’m looking to do in the more complex logging is for tracking things in progress/working/new/no long used for references, still working out the details on it though. Absolutely agree on the backup, I pull spare copies all the time. 


Reply