Mobility Upgrade to our Virtual Tour Display Software

  • VIF has been producing virtual tours for Vacation Rental and Real Estate companies in the Coastal Carolinas, USA for the past 14 years. 3 years ago, we switched from commercial software to our own krpano-based custom software designed to run on desktops and laptops only. We are currently in the final stages of developing our first Mobility Upgrade which provides access to a broad range of tablets and smartphones. At the same time, the primary lessons we learned in developing for mobile devices - efficient use of screen real estate and simplicity of functionality - have been fed back to revamp our desktop version.


    A screenshot of a tour running on an iphone 5s under IOS 8 is shown here:


    A fully-functional demo tour is available here for viewing on your device of choice:


    http://virtuallyinaflash.com/demos/krpano/viewer.html


    Best Regards,


    Tom Black
    Owner, VIF Design

  • It seems to be very heavy for some reason and crashes very quickly on an iphone4. Also some elements are misconfigured, visible true but alpha 0 which leaves dead zones on the screen where touching the screen is impossible. I'd also like to see a working portrait layout. It's an annoyance to be forced to switch to landscape and unlock orientation just to view it.

  • 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

  • 1. Yes physical devices. Looks like its a memory issue. I would use different pages and openurl if you want to go that method so that you don't have to worry about memory getting freed properly.

    2. There's a large dead zone in the middle of the screen which prevents panning. I assume this is something left over by mistake. On Mobile it takes a much larger area so it's very noticable. By using individual graphic elements you can create much nicer interactivity with onover onout crops and all matter of tweens. You can still using a single photoshop image as a sprite by using these crops.

    3. you can always show a message in portrait that you need to rotate to access x features, using one or the other can engage an unobtrusive view of the image for example.

    4. Another major annoyance, is the auto-rotation and being forced to find the stop button to interact. I would automatically stop it with events.onclick and turn it back on using onondle. You can kind of drag it currently with a wrestling match with the autorotation.. and that looks a little ugly.

    5. on the desktop the thumbnails are some are positioned halfway off the window on smaller resolutions. Also, I would make them dragable also. Followmouse seems like a good idea but it quickly breaks down for large numbers of thumbnails. It's also a rarely used UI. Drag is easier to understand.

    6. Desktop: another thing is that the graphic elements scale to the screen size. If I'm using a smaller window, they all become too small to use and illegible.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!