SL Mobile: Thoughts on Device Screen Sizes and HUDs in the New Era

[Glaznah Gassner]

I was recently responding to a related topic here and decided to pull some technical statistics from our SpeedLight Viewer Google Analytics. Among the data, the screen sizes particularly caught my attention (don't pay much attention to "low resolution", it is "virtual pixels" size):

 

As experienced Second Life creators, we've become accustomed to designing for large landscape screens. We assume the screen is wide and spacious, making HUD devices clearly visible and easily distributed across the screen width.

However, when you look at the most common screen proportions today, you'll notice that many users are now using portrait screens. This change means that the HUDs typically placed side-by-side may overlap or clash with each other. Additionally, the buttons and captions on these HUDs can appear quite small on mobile screens.

With an increasing number of users accessing Second Life from mobile devices, it's essential for creators to completely rethink their approach to HUD design!

 

UPD: the resolutions above are not physical (pixel) screen resolutions. It is a virtual values reported by Google Analytics. For example, iPhone 14 reports 430x932 virtual size.

Edited August 30 by Glaznah Gassner

[Gabriele Graves]

If you run a service that streams all the graphics to a mobile device then you are going to be able to support very old and low end phones, etc. (no matter how slow they are) because in the end it isn't much different to watching a youtube video and most phones can support that in some way.

However for a full mobile app such as the one from LL, there is no way devices with resolutions as low as the ones indicated here will work simply because their GPU isn't beefy enough, they don't have enough RAM and most likely that their operating system is too out of date.

Full mobile app users are almost always going to have at least a HD screen and a modern mobile GPU and so I think the statement here about HUDs would only be true for streaming users.

Edited August 30 by Gabriele Graves

[Cynite00]

This is where LUA enters the arena, as it can be used to make scalable, responsive HUDs and UI elements, and run on top of SL. Most UI addons in WoW were made with LUA scripts.

eg. https://docs.zerobot.net/lua_scripting/functions/hud/

Edited August 30 by Cynite00

[Love Zhaoying]

Assumption: Resolution actually only communicates "pixel density" and not "physical size" (although the two could be related).

I was looking at your list above and thinking initially, "those with the lower resolution are probably 'older phones'" etc. 

I use an older phone (with a smaller screen). But when I do finally upgrade, I don't want a LARGER phone, just a higher resolution!

So, those with the "smaller resolution" in your list MAY be "older", or MAY be "smaller"..?

 

[Love Zhaoying]

1 minute ago, Gabriele Graves said:

If you run a service that streams all the graphics to a mobile device then you are going to be able to support very old and low end phones, etc. (no matter how slow they are) because in the end it isn't much different to watching a youtube video and most phones can support that in some way.

My understanding was, that Speedlight doesn't really "stream" all the graphics to the devices. I'm sure @Glaznah Gassner will correct me if I am misspeaking.

[Glaznah Gassner]

Sorry, I have not explained. "390x844" by Google Analytics is not a physical device resolution. It is a "virtual pixel" screen size.

For example, iPhone 14 Pro Max has 430x932 virtual resolution reported (with 2796 x 1290 actual screen).

What I'm saying is that screen is portrait. And even modern devices are much smaller than any desktop screen.

[Gabriele Graves]

1 minute ago, Love Zhaoying said:

My understanding was, that Speedlight doesn't really "stream" all the graphics to the devices. I'm sure @Glaznah Gassner will correct me if I am misspeaking.

It must do if it is getting mobile users for those resolutions, there's no way devices like that have anything like a GPU decent enough for anything on the phone to render the graphics.

[Glaznah Gassner]

2 minutes ago, Love Zhaoying said:

My understanding was, that Speedlight doesn't really "stream" all the graphics to the devices. I'm sure @Glaznah Gassner will correct me if I am misspeaking.

Yes, absolutely correct. Streaming the graphics makes no sense (Linden Lab tried that years ago, and gave up).

Both SpeedLight and Second Live Mobile Viewer render graphics directly on user's device (using GPU).

[Love Zhaoying]

5 minutes ago, Glaznah Gassner said:

It is a "virtual pixel" screen size.

What does this actually mean?

6 minutes ago, Glaznah Gassner said:

What I'm saying is that screen is portrait.

I never remember to try "anything" in "landscape" on the phone, not even videos!

[Gabriele Graves]

OK, thanks for the clarification I don't know what "virtual resolution" means in this case then or why that is important.  Is it a dpi/ppi type measurement?

A 10" tablet with a resolution of 2796x1290 isn't going to have the same pixel density as a 6.6" phone with the same resolution for sure.

[Glaznah Gassner]

Just now, Love Zhaoying said:

What does this actually mean?

We see 430x932 screen size in statistics, but each virtual pixel contains 6 physical pixels.

Industry does this to avoid getting extremely tiny user interface elements on modern phones (relates to "DPI").

[Glaznah Gassner]

4 minutes ago, Gabriele Graves said:

OK, thanks for the clarification I don't know what "virtual resolution" means in this case then or why that is important.  Is it a dpi/ppi type measurement?

A 10" tablet with a resolution of 2796x1290 isn't going to have the same pixel density as a 6.6" phone with the same resolution for sure.

Yes, it is dpi. 

Imagine the app has been developed years ago for 1024 pixels screens. If we keep using physical pixels, all app controls (buttons and such) would be 1/2 smaller on new 2048 pixels phone.

[Gabriele Graves]

Just now, Glaznah Gassner said:

Yes, it is dpi. 

Imagine the app has been developed years ago for 1024 pixels screens. If we keep using physical pixels, all app controls (buttons and such) would be 1/2 smaller on new 2048 pixels phone.

Might be a good idea to update the OP in that case to clarify for other readers/responders because it's a little misleading as it is.

[Gabriele Graves]

I've never used Speedlight and only recently the LL mobile viewer.

I could not imagine using it portrait orientation only.  It would be far too cramped.  For the limited playing around with it I've done, I've always used it in landscape orientation.  So yes, HUDs and other on screens windows would be an issue.

A couple of thoughts though:

• I believe LL has added or are in the process of adding the ability for the HUD to know the "screen size" from LSL so that HUDs can adapt.  I'm not sure what it would report in this case, actual resolution or virtual resolution but I'm not sure it would matter if the issue is mainly portrait vs landscape as the ratios for any measurement would tell the script if the device viewport is portrait or landscape.  So that is one route to HUDs being able to adapt.
   
• For mobile, LL and others could render the HUDs on one or more dedicated views which the user would have to switch to in order to interact with.  The all on one view approach obviously wouldn't work well in this case anyway.  You can see that keeping things off the main view is how LL seems to be approaching their mobile viewer for other settings, etc.  It will be interesting to see what they do with HUDs generally as they currently don't have support for them, they just don't load in any form not even for running their scripts.

 

Edited August 30 by Gabriele Graves

[Glaznah Gassner]

1 minute ago, Gabriele Graves said:

I believe LL has added or are in the process of adding the ability for the HUD to know the "screen size" from LSL so that HUDs can adapt

This is what I mean. Currently all HUDs expect to reside on a large landscape screen. Creators need to adapt them (increase button and text sizes, consider portrait screen).

1 minute ago, Gabriele Graves said:

LL and others could render the HUDs on one or more dedicated views

Excellent idea! This is what we are experimenting with (SpeedLight has no support of HUD devices yet). On one hand, this approach solves the problem. On the other hand, users expect HUD to be Head-Up-Display, not a "separate control panel".

What if @Linden Lab join our discussion?
HUD devices support is a 2nd popular request in SpeedLight wishlist (after 100% reliable avatar rendering).

[Gabriele Graves]

25 minutes ago, Glaznah Gassner said:

This is what I mean. Currently all HUDs expect to reside on a large landscape screen. Creators need to adapt them (increase button and text sizes, consider portrait screen).

Excellent idea! This is what we are experimenting with (SpeedLight has no support of HUD devices yet). On one hand, this approach solves the problem. On the other hand, users expect HUD to be Head-Up-Display, not a "separate control panel".

What if @Linden Lab join our discussion?
HUD devices support is a 2nd popular request in SpeedLight wishlist (after 100% reliable avatar rendering).

Thanks and yeah HUDs are critical for my own use of SL.  Just one example is that my body's alpha cuts aren't kicking in on SL mobile due to HUDs not being loaded and their scripts running.  So my feet are visible and in the wrong orientation which kills any desire to use the mobile app any further.  AOs are another problem for most as they tend to be HUDs as well and without those working, might as well call it a day for many potential mobile users.

Edited August 30 by Gabriele Graves