What's your Story Size?

Jun 21, 2012

"They" say size doesn't matter, but in the case of eLearning it does. At least when it comes to the iPad App.

If you want your Storyline course to fit nicely on an iPad (iOS), your Story Size needs a 4:3 ratio. This 4:3 ratio is the default in Storyline, which is 720 X 540.

Now, for me, 720 is too narrow; considering the minimum resolution being 1024X768 on the desktop. I'm losing (giving up) a lot of desktop real estate at 720 (just for the sake of the iPad).

I'd like to hear from others:

  1. Now that you can change your Story Size, are you? Or you find yourself working with the default?
  2. How important is it that your course fits snug on the iPad (iOS)? Do you consider this?
  3. Is the iPad even at all important in your course delivery?



76 Replies
Steve Flowers

I'm setting most of mine at 960x640 (taller than 16:9 supports some extra space for custom navigation elements). The fit to iPad is more about proportions than width. This setting letterboxes slightly. 

The other consideration is the appearance of the side menu. I've managed to squeeze a few extra pixels at 4:3 for good iPad fit while still fitting the side menu into a 1024x768 display on the desktop. This setting is 756 x 567. I don't use the side menu, but if I did I'd go with 756x567.

Kevin Thorn

Great question, Ryan. We're in an era that makes us think through delivery with added devices and screen resolutions. Most desktops now come with widescreen 16:9 ration monitors. While iPad and the more common of the Android tablets are at 4:3. 

@Steve, the 756 x 567 is great to know. Thanks for sharing that! As for sidebars, I typically don't use them. If there is a menu, I'll move it to the top player as a dropdown.

Now here's where I poke the bear - I'm not in the camp that designs for desktop AND mobile. I design the learning first. If there is a request or need for multiple deliveries, I develop one for each. Yeah, I know it's more work on the front end but the end user experience is richer and I think better quality. Besides, it keeps me from having to keep up with what works/doesn't work on iOS or HTML5. Design for desktop I'm free to let go.

Kevin Thorn

@Steve, I'm finding a deliberate focus designing for iPad. It's almost an entirely different approach because you have to make design decision especially around interactions and navigation on what works and doesn't work. The sidebar menu is just too small to manipulate on an iPad so the navigation is designed on-screen. If the same module is designed for desktop, I can use the sidebar without regard.

Differences between "Click and Drag" vs. "Tap and Swipe" I suppose.

Ryan Martin

Guys, thanks for sharing.

@Kevin - Clearly there's a problem with Storyline's mobile solutions when you need to make two products for one solution. I've suspected this myself as I've tried to find "workarounds" as I compare desktop to iPad over and over again; never happy with the compromises I (need to) make.

@Steve - I suspect you know where I'm leaning here. A grid layout. I know you dip quite deeply in web design waters; seeing responsive web design solutions then coming back to our elearning world where we have solutions like Kevin suggested (doubling our workload) is frustrating. It is what it is.

I've been playing around with a 988 X 643 Player Size.

This works with the 978 grid system (use the Player border as extra 10px left/right margin), and fits nicely at 1024 X 768 ... and on the iPad ... in HTML5.

988 X 643 WAS suppose to be my kill two birds solution, but since building (as I build) HTML5's limitations (bugs) keep cropping up. This on top of A) The community seems to always suggest & lean towards the iPad App over HTML5 solutions B) The Storyline showcase displays no HTML5 solutions (I do remember seeing the Green Monster in HTML5).

This has me and my 988 X 643 player size back at square one. I have no faith my end solutions will work well in HTML5. As far as the iPad app is concerned, we're limited there in obvious ways (user experience).

I'm not at a point where I'm dropping mobile solutions, but I'll also say, I'm not at a point where I'm pushing a mobile solution to clients.

In a nutshell, my Story Size question is more to do with grids, design patterns, reusable components (buttons, side menus, etc.), and multi-device solutions. Kinda a 80/20 rule applied to rapid development. Efficiency.

Kevin Thorn

Hey Ryan,

You're doing a lot of testing in an area I've been meaning to dip into but don't have the time. As Steve mentioned, I've tinkered with the 960 grid as the psuedo-standard, but I'm interested in your 988 x 643 player size. I'll have to play with that.

Like you, I'm not dropping mobile solutions. Elarning for mobile is fairly new in terms of "designing for mobile." I still get requests to "convert" old instructor-led classroom training to elearning - not the same instructional design.

I don't hold the authoring tool to blame at all. Desktop is one solution. One environment. Mobile is another. Different solution, environment, atmosphere, and accessibility. Most often mobile is (should be) for performance support. It's more about the delivery strategy I think rather than a single design should shovel itself into every possible mode and platform. That's just not good design.

In addition, it's the current state of browsers, HTML5's progress, and Apple's iOS. Can't hold Storyline at fault. That said, Storyline is by far one of if not the best tool for build once, publish everywhere if that's your design. 

Good stuff!

Ryan Martin

Those fat 30px margins in the 978 are sweet. Try it out if you haven't.


@Kevin - I hope I didn't come across as sounding like, "What you're doing is wrong"; your multi-device frustrations are clearly mine as well. And, you summed up your solution nicely, "Besides, it keeps me from having to keep up with what works/doesn't work on iOS or HTML5."

Kevin Thorn

See, now I gotta try that width now, too!

Not at all Ryan. Not at all. It's all part of our world and the many layers we in this industry have to keep up with. The underlying layer and behind the scenes techno-geekdom is a necessary evil in order to professionally consult with client's wants/needs. 

I see more often than not clients 'wanting' mobile with zero strategy or reason why they want it other than it's "cool." Like you, I don't promote it, but if there is a legitimate need we then go into new requirements conversations about the differences and expectations. Plus the additional cost for the extra time.

Apologies if my rant came across the wrong way. I get kinda passionate about this stuff.

Nick Moffitt

I recently posted a similar query related to Story Size on the iPad "Working around the iPad's limitations".

Bottom line: I'm not able to get slides with screen recordings to play if the Story Size is larger than the iPad's XGA resolution (although non-recording slides in the same SCO play correctly). I'm recording my application at 1440x900, using that for the Story Size and setting the Storyline Player to scale to the browser. Safari Mobile does not support scaling for HTML5 (but it works on Chrome with HTML5), so the recording plays back as a black screen. 

I just tried the Articulate Mobile Player and my 1440x900 story plays great... but I need user log-in and LMS tracking. I might end up publishing the same material on the LMS in two different Story Sizes, but a the same 1.6:1 ratio. 

Ryan Martin

@Steve & Kevin - What's your experience with "Launch player in new window (creates launch page), Display window with no browser controls, Allow user to resize browser.

I come from the camp that says pop-up windows of any kind are annoying; so I shy away from this option. But. I am giving up height to the browser chrome. This height would bring my 988 solution closer to a 4:3 ratio.

From my playground (testing ideas) ... 988X 643:


For fun, here's a responsive design I was trying out a while ago, never got around to finishing it ... I had plans for this one ... Boy, did I have plans...


/Need to do more procrastiworking.

Steve Flowers

Larger sizes also have a filesize / bandwidth effect. I'm really liking the split difference between 4:3 and 16:9 offered by the 960 width. I'll have to give Ryan's dimensions a whirl.

The advantage to going with a width with a grid system, Gerry, are some of the tools setup for layout and positioning (C.R.A.P.). These frameworks build in whitespace consistency. The things we try to do (mostly successfully) just get a little more consistent and possibly a little easier if we can get into the habit of using them

The 978 grid system is setup for responsive layouts. Take a look at this demo:


The darker bands can be grouped together. The idea is to always have a "gutter" between columnar groupings of elements.

Here's the grid I've been using for Web design stuff. Scroll to the bottom of the front page for a nice visualization of how the grids apply to various designs (hit the "Show Grid" button above the screenshots).


You can generate a grid for practically any dimensions:



These are really popular in Web design. I wouldn't be surprised if most of the professionally developed sites you see have a grid artifact hidden away somewhere.

Todd Thornton

I'm curious if anyone is contemplating a possible "post app" scenario? On a desktop, I always have multiple windows open and never personally view e-learning/training in full screen. Of course on Android tablets you've always been able to have multiple widgets open and while I appreciate and understand most people today are using Apps on all devices full screen, unless e-learning designers start creating far more immersive environments (like existing games) could the desire to have multiple windows operating at the same time/true multi-tasking/split screens trump the benefits of using individual apps?

If I understand it correctly, the iPad apps that provide multi-tasking/dual web browser functionality are really starting to grow in popularity and with the resolution of the newest Retina display you'd expect more of those to come online, but that doesn't have to be accomplished within an app. With the increased resolution, two separate HTML windows/pages in landscape mode would still result in each being very easy to see/read. 


Ryan Martin

@Kevin - Wow! Must be first gen iPad thing? This should work on your iPad: http://www.elearnerengaged.com/ipad/story_html5.html

I'm completely at a loss.

@Kevin, @Steve, @Phil, @Gerry: Are you guys utilizing HTML5 Output at all? Or is your mobile strategy the iOS app?

I'm feeling like I'm barking up the wrong tree with HTML5 output and should be concentrating on iOS... OR, I should come to terms, I don't have a mobile strategy ... just yet.

Kevin Thorn

@Ryan. Odd. That's the url that auto loads when I go to your first posting of the link. White screen. I'm chalking it up to my device but I did see it in a regular browser and intrigued by the 988 size.

I don't have a specific mobile strategy that I offer as a service. When clients propose the notion of mobile output, the discussion then turns to defining the requirements and really digging deep into their "we want this to be delivered on mobile." The several who have posed the idea, only two so far actually had a delivery strategy. One was iOS and the other HTML5. But again, these were additions to the desktop model so in the end they were more performance support than true mlearning. There's just too many moving targets right now with iOS not connecting to an LMS and the user management efforts of tracking learning via an LMS with mlearning. Once clients realize the efforts they realize they really don't have a strategy to begin with.

Like you, I keep tinkering with ideas just so I'm up on the latest on what can and cannot be done from a design and development perspective. No doubt the industry is quickly moving in that direction and the days of desktop, mice, and keyboards will artifacts for the time capsule.

BTW: I'm working on a layout now at 1000 x 650. Fits nicely. This of course is with no sidebar. Navigation is designed within the screens.

Gerry Wasiluk

Ryan Martin said:

@Kevin, @Steve, @Phil, @Gerry: Are you guys utilizing HTML5 Output at all? Or is your mobile strategy the iOS app?

All my projects so far have been aimed for the desktop and Flash. Some client interest in more than that but no work yet.  So far all I've done is just "play" with HTML5 and iOS or demo it to others.
Ryan Martin

I think I may have an option.

What would be the problem with having a Story Size of 1024 X 768 ... plus... Browser size: Display at user's current browser size ... plus... Player size: Scale player to fill browser window

1024X768 is the same ratio as 720X540 (4:3). Meaning this scales to fit nicely in the iOS App.

Side note: Regarding the iOS app, why is there a "Pinch/Zoom" (Use to enter/exit full-screen mode.) ... the default is a scaled down player size; so if you are designing to fit (4:3), the learner isn't getting this, and, in my opinion, it's not intuitive they can scale up.

Link to the latest scheming session:


p.s. I'm noticing embedded YouTube vids are "buggy" in the iOS app ... ? Hmm.

This discussion is closed. You can start a new discussion or contact Articulate Support.