Make the game interface fully responsive & embeddable

So, I tried embedding an eterna puzzle into an 800x600 iframe. This is what happened: http://prntscr.com/7npgl7

That caused me to realize a couple of things should probably be addressed:

  1. Not only is the interface (both in the title screen and in the game) missing elements when embedded, but in smaller browser windows as well. I believe it used to just get scaled (could be wrong), but now it juts clips stuff off. I would like to see the interface adjusted so that both smaller window sizes can be used (I’m sure it could be helpful in some situations), as well as make embedding more of a reality. And scaling is not the sole answer here, as if I wanted to have, say, an embedded puzzle fill the whole page but only go ~600 pixels down, that would mean the whole thing would be a bit of, well, a stretch. Elements should be able to be scaled with their own ‘aspect ratio’ preserved if they need to shrink, and simply rearranged to fit on the screen size as the primary adjustment.

  2. It would be cool to see a special EteRNA app specifically for embedding. This way, I could, for example, put it on the wiki, and users could simply log into it if they aren’t already (through the app), and play whatever puzzle I specified (ie, to teach a specific concept interactively).

If the app is embeddedable, it could lead to some neat possible advertising opportunities, and as I mentioned, a helpful tool for teaching (specifically on the wiki).

1 Like

As far as I can tell, embedding works fine.  As you note, it will start losing UI elements if either width or height gets small enough, but I don’t notice anything different from a small embedded window and a full browser tab shrunk down to the same size.

In case you got different results, here’s the two ways I tried it.  The first is simply embedding the flash game:

The second puts the whole Eterna site into an iframe.  I see no difference as long as I’m in the flash game, but the iframe approach allows access to all Eterna, while with the embedded version, the user can’t follow links to other Eterna pages.

I do understand that an iframe does not change anything. However, I do think the re-size clipping is an issue, and it would be useful to have some extra elements in an embedded version.

I just looked at the code for the mission screen. It seems the Nova team very deliberately designed the UI for 1024+ pixels widths. Lower widths still “work” until 841 pixels wide is reached. Any lower starts indeed to look ugly… Improving things there would mean efforts that I’m not sure we want to invest just for the sake of embedding.

With the game interface itself, I’ve been working on unrelated changes recently, but these do impact (a little) the way the applet looks and things are possibly already improved. Check out some puzzles or labs on my dev instance http://nando.eternadev.org/web/

On the general idea of having UI elements capable of “stretching” or “scaling” themselves, I would tend to disagree with that, on the grounds that, even though we don’t have precise demographics, it is known that EteRNA players are represented everywhere in the age pyramid. Readability is an important issue, and I do believe that maintaining a minimum or static size for basic UI elements (bases, buttons, fonts, etc) is very important.

Personally, I wouldn’t think it would be too hard to detect screen size, and rearrange/scale the appropriate elements accordingly, but I haven’t seen the code. I’m just thinking about responsive websites, where that is very much standard. Personally, I just see this as something possibly helpful, and would love to see it utilized in the wiki. Of course, I’m sure it’s not the highest priority of things, as it still could work.

I think the mini menu is a cool idea, actually. Gets rid of some extra noise. I would center everything on the right hand side though… Just a thought.

Of course you do need to consider a smallest possible size, however I honestly do not know if there is much room that is available, specifically for things where there is only a single large graphic, it does not need to be too large (namely, all tools on the bottom besides the nucleotide choices).

The new use of the mini menu in large windows is problematical.   iI make it significantly more cumbersome to use all the capabilities that get tucked away.   But also, if you like to keep the dot plot open and minimized while making changes (as I often do when working on labs), the mini menu isn’t functional.

If compromises in the UI need to be made to support unusually narrow windows , I hope we’ll degraded the functionality only when it is necessary.  Maybe a setting to use the mini menu?

1 Like

Omei, I totally agree with you.

As is, the more I see the new mini menu, the less happy I get about it. Because it causes an amount of extra clicking and disrupt the game flow.

What I wish is if we can get an option like in the games menu, so we can each choose which buttons are important to us, so we can have them shown.

Nando, I don’t want to speak for Eli.  But the two changes you made (making the mini menu pop up w/o a click, and rearranging the z-ordering of the dot plot and mini menu) address my concerns.  Thanks.

1 Like