A few years ago a colleague of mine and fellow developer, Craig Verrastro, invited his daughter’s music teacher to come present to my department. Why? Because he was seeing impaired, and we wanted the team to see what browsing the web (especially our own applications) was like for someone using a browser for the visually impaired. There were many very interesting moments during the exercise, but one really stuck out for me. At one point he encountered a site that detected that he was using a seeing impaired browser, and redirected him to a simplified version of the site, which was also the site’s “mobile friendly” version. This frustrated him and he immediately found the link to go to the full site. He pointed out that he disliked sites that did this. He said he noticed most people with normal eyesight often disliked these sites just as much, “who wants only a part of the site? No, I want the whole site. If it’s interesting enough to go on the full site, why wouldn’t I want to get it too?” He had a great point and I feel many mobile users feel the same way. I have not found any statistics, but I feel most mobile users do not mind a site optimized for their device, but don’t want some sort of reduced experience.
Month: February 2019
When I was a teenager I had a job at Burger King. If you have never noticed it before, there is a large digital clock next to the drive through window, which tells the employee how long the cusotmer has been waiting for their order. Measuring drive through wait time is a core KPI (of course, this was before I know what core-KPI meant) for these stores. In the end, what this really meant was that the drive through attendant would often just hit the “served” button as soon as the car drove up to window, instead of when the customer was actually served their order. To counter this, the stores started installing pressure pads underneath the drive through windows, to detect when the car actually drove away instead of relying on the teenager at the window. This is the real reason they will sometimes ask you to pull through and they will bring you your food, instead of making you wait at the window for a delayed order – it’s not for your convenience, they want to get you off that pressure pad.
This is a trick that I have used many times which I first learned about on Mkyong.com – one of my favorite Java/Spring/Hibernate resources.
Just about any application will need to connect to external resources like databases, web services, file servers, and the like. And, if you are working on a corporate application or in an environment where your source control system like SVN or GIT is not a safe place to keep passwords, this can cause quite a security conundrum.
Enter Spring’s PropertyPlaceholderConfigurer class, one of the handiest little classes. It’s actually worth adding Spring in your application just to get access to this little gem. What this does is it allows you to load a properties file into your Spring configuration XML, and use its properties – thereby removing the sensitive content from the XML file.
So it seems that every job I work on, the same topic comes up. Someone, at some point will say, “just use an iFrame for that”. Then I need to go down the old tired road as to why that would not be a good idea.
Well, this article is going to be a bit utilitarian for me. I hope to put down in a single place all the reasons iFrames are not a cure-all solutions so that I can save myself some time in the future and just point people to this URL. As such I may update this post on occasion as I refine these points. Feel free to use this post for that same purpose if you like, and please post any suggestions or points I have missed to my twitter account (@rwbDev), I’ll be sure to credit you if I add the point to this article.