Sachagriffin,
thank you for your comments which are greatly appreciated. I would like to respond to them as follows:
1. I am not sure to what you refer as 'heavy' but I suspect it may be the transition between the Menu and its component items, the Virtual Tour and the Slideshow. These are switched in the HTML wrapper via javascript and the removepano() and embedpano() commands rather than within krpano itself for reasons related to a furture extension to the software. They do indeed result in a clunky transition and I am working on improving this. I am obviously concerned with your experience with the iPhone 4 I included an iPhone 4 emulator in a broad range of cross-browser/device testing and found no problems; but emulators do not tell the whole story. Did you experience the crashes on an emulator or on the physical device? I would very much like to know.
2. The elements with visible:true and alpha:0 are actually "invisible" buttons and require a little explanation. I use invisible buttons extensively in designing both for desktops and for mobile devices. It allows me to construct a button bar or menu as a single, graphical element (usually in Flash or Photoshop) and then cover the indiviual buttons in the graphic with clickable invisible elements which are usually positiomed dynamically with an action (e.g. set_btn_dims()). The invisible button itself is preconstructed graphically as a (say) red png image with alpha = 0.5. The button is then set in a krpano element with visible:true and krpano alpha:0 so that it is clickable but invisible to the user. For testing purposes during development, I can then temporarily set the krpano alpha to 1 which reveals the buttons as translucent elements which hopefully, If my programming math has been correct, are accurately positioned over the composite graphical faux menu. Without exception, the buttons throughout the demo are active, invisible buttons which can hardly be considered dead zones. I am, however, guilty of redundancy, since visible:true is the default value anyway.
3. You raise an interesting philosophical question regarding the use of orientation on mobile devices which typically feature high aspect ratio screens. Here are my thoughts for what they are worth. To begin with, I had imagined that most people use their smartphones with orientation unlocked - perhaps I was wrong. To me, the availability of orientation provides another degree of freedom, an extra dimension in which to present content and functionality. The virtual tour is almost uniquely suited to take advantage of this freedom. It presents well on wide (landscape) screens and in fullscreen mode. The inclusion of control buttons is more easily and (I believe) more logically achieved in landscape than in portrait mode. The portrait orientation can play a useful supporting role in providing means for exploring a specific scene via gestures and possibly manual directional/zoom buttons. As you have seen in the demo, rotating the 'landscaped' virtual tour (whether autorotating or not) to portait view, pauses the scene and allows manual exploration with gestures and/or control buttons. Getting user to this happy state of bi-rotational functionality obviously requires a degree of finesse - the opening Portrait animation is but a first step at 'gentle persuasion'.
Again, thank you for the comments,
Best Regards,
Tom Black