In the cor­por­ate en­vir­on­ment there’s a com­mon mis­con­cep­tion con­vert­ing a design for desktop-wide screens is as easy as mov­ing the left and right side­bar above and be­low the main con­tent re­spect­ively. To all in­volved parties’ dis­may this is not really the case. You can find many pages on the in­ter­net writ­ing about the best re­spons­ive design prac­tices (such as mo­bile-first design), how­ever there’s none, or al­most none, about tech­nical gore such as view­port (if one dis­reg­ards the meta tag) and ne­ces­sary UX con­sid­er­a­tions to ac­count for some­what small smart phone screens.

Dis­claim­er: I’m not a de­signer (nor UI, nor UX) so spare me.

Sta­tion­ary view­ports

I was in pro­cess of tak­ing care of front end of yet an­other web-­based ap­plic­a­tion which got its re­spons­ive design made from yet an­other ter­ribly thought out desktop-s­ized design. Then a really strange bug from qual­ity as­sur­ance 1-per­son-team about view­port jump­ing around got as­signed to me. It read:

After a but­ton is clicked the next page opens, but with the win­dow jumped off to odd loc­a­tion.

The bug puzzled me at first as no form of view­port ma­nip­u­la­tion was done what­so­ever at any point of ap­plic­a­tion. As I nav­ig­ated to an­other page real­isa­tion hit me the cause was noth­ing else than the method we use for load­ing pages.

The ap­plic­a­tion in ques­tion hap­pens to use AJAX for load­ing page con­tent and the is­sue could eas­ily be re­pro­duced only after nav­ig­a­tions from con­tent-rich pages to pages with al­most no con­tent at all. View­ports simply do not move around without a reas­on. Quite the con­trary, they stay as close as pos­sible to their ori­ginal loc­a­tion and as amount of con­tent shrinks, parts that ori­gin­ally were in­vis­ible be­low the view­port come up be­com­ing vis­ible.

In­deed, the “odd” loc­a­tion was al­most al­ways the footer of the page be­com­ing vis­ible as the newly “loaded” page con­tained a tiny amount of con­tent com­pared to pre­vi­ous page. This an­im­a­tion il­lus­trates the is­sue quite well.

Con­trolling the con­tent

The ob­vi­ous way out in this case is to make sure there is no way to let user get into situ­ation in which user can ob­serve the “view­port jump” – en­sure user’s view­port is never close to the bot­tom of the page when present­ing an act­ive re­gion which causes a change of con­tent. Put but­tons and links to­wards the be­gin­ning of be­fore the con­tent in­stead of after it, for ex­ample.

For more ap­plic­a­tion like pages such as games or quizzes it could be sens­ible to simply make sure all views/pages are sim­ilar (or equal) in height mak­ing height of the page more or less con­stant too and avoid­ing the prob­lem al­to­geth­er.

Con­trolling the view­port

If the con­trol of con­tent is im­possible due to its dy­namic nature, con­trolling the view­ports is the other way out. View­ports are a part of ob­serv­able user ex­per­i­ence and hop­ing for the best just will not do. Neither will scrolling to (0, 0) on every view change, es­pe­cially on mo­bile devices, where it is un­usual for header to oc­cupy most of the screen.

As much as one would like to have one solu­tion fits all thing, there is no such thing. One must ac­count for vari­ous vari­ables such as loc­a­tion of chrome (head­er, foot­er), the pri­or­ity of con­tent, ac­tion area loc­a­tions, cur­rent view­port size and so on. Scrolling to the be­gin­ning of con­tent area when an­other page is loaded should gen­er­ally be a good choice, though.

And do not ever move the view­port some­where without ex­pli­cit user ac­tion.

To sum­mar­ize, the browser view­port is a part of ob­serv­able user ex­per­i­ence. Do­ing noth­ing with it (espe­cially in dy­namic ap­plic­a­tions) will burn you and make the ap­plic­a­tion look some­what un­wel­com­ing.