So how should you approach this challenge? First determine the smallest view screen size you are required by your client or management to support. How would you find this out? Do research! In corporate environments it’s quite common for the IT department to run ‘auditing scripts’ as a normal part of each user’s login procedure. (Yes you COULD just change the display dimensions in the HTML file to make everything fit, but that will not usually save your bacon because many interactive elements such as buttons or links simply become too small to be easily usable and your target audience will likely start to complain about usability. But it’s quite common to find mobile phone screen resolutions will NOT be able to accommodate the height or width of existing course content. iPads and other similar tablets nowadays have screen resolutions that rival or even surpass many desktops and laptop PCs. The situation becomes much more complex the moment you are obligated to support hand-held mobile phones as well as desktops and tablets. What this all means is that targeting desktop users will almost never require changing the project height or width of an older e-learning course because the content will normally be far smaller than the screens being used to view them. ![]() But almost all of the people were using resolutions above 1024 pixels. Note that the most common resolution by far was Full HD 1920 x 1080. ![]() If you don’t believe me, take a look at the screen capture at right taken from my own Google Analytics report showing screen resolutions for visitors over a single 24 hour period several years ago. Most desktop or laptop users are now running screen resolutions well in excess of 1200 pixels wide, and the majority are likely to be running resolutions of 1920×1080 pixels (i.e. They just need to play at some size that falls within the borders of the screen resolution and is comfortable for the viewers.ĭesktop users are the easier ones to accommodate for HTML5 conversions because their browsers can easily stretch or shrink to fit the course content. E-learning courses don’t need to fill the user’s entire screen. If so, that pretty much solves your target audience issue, and will usually mean there is no need to consider reformatting the course dimensions. So part of your job as the ‘e-learning expert’ on the team is to make sure all stakeholders are well educated about these issues before management can make a mistake and blame it on you. By the time they find out it’s not really what they want, it’s usually too late. However, an important issue for Captivate developers is that when managers make the decision to go responsive, most are totally unaware of the fact that their training budget will build far fewer responsive courses than normal ones, or of the fact that changing their mind later to return to non-responsive projects is simply not an option because it means ditching the responsive course/s already built. ![]() (This probably explains why previous surveys I’ve conducted from this website show only a minority of participating Captivate developers chose responsive HTML5 as their main project output.) ![]() That translates out into a lot more development time and budget. Another issue with responsive projects is that they can take a lot longer to build and place many more limitations on what you can include as far as functionality. The extra time gets eaten up due to the fact that responsive projects need to be designed for anywhere from three to five different screen sizes (if you go break-point responsive). Instead of just arranging objects for a single slide (as in normal projects), responsive projects require the designer to configure the output so that those same objects can look good on devices using vastly different view-port sizes and orientations.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |