Designing the responsive app with unified.Shell, m...

alex_myakinkii · ‎02-19-2019

Intro

Being an sapui5 developer means you follow the fiori design guidelines while developing your enterprise apps, so that you present user consistent UX across your apps suite.

But what if you have an idea for a side project or a custom app, but your skills are mostly revolve around ui5, and you are not going to design a lot of new stuff?

That would probably mean you start experimenting with existing controls so that you turn it into your desired ui.

And this is exactly what happend to me when I decided that I want to create a ui5 based prototype for a game. And I honestly believe it ended up being not so ugly. Probably )

What I also would like to mention - is that I really love ui5 for all the stuff it gives you out of the box.

I am neither a real frontend developer (who can leverage a lot of tools or frameworks) or a designer (who can instantly create beautiful stuff), so I really appreciate the idea that I just can take all the controls, mvc, i18n stuff, and instantly extract value out of this.

So, this makes it really cost effective approach from my perspective even though your prototypes can end up being cancelled or discarded.

Application goal

So the initial goal was to recreate an old and legacy ugly ui I had for the game, so I just wanted to move (or even copy the UX) this stuff entirely to ui5 while providing bot the desktop and the mobile versions of the app.

And this is where another point I missed earlier comes into play as a real major feature - responsiveness.

When we build fiori apps, we mostly design for desktops (at least myself), and only in certain cases we consider an option for this ui to run on a small screen ui (not even a tablet, but a phone).

So, the responsiveness of the controls added a a lot of value here to me as well.

The legacy ui had chat or lobby with players, parties and other stuff, as well as the actual game ui.

So, the first approach was to split it into some parts and implement it as pages.

Here what it looked like on a modern desktop screen:

Carousel + Shell

Now as I am browsing through the commits it looks like the initial design just used the Carousel as root control with all the pages added as fragments to pages aggregation.

This way on a mobile device it would provide you with a fancy swipe to another page ux.

Also, after considering some options for the app layout I decided to give the unified shell a go because of this sample with a dedicated user stuff.

The first commit I can find now already includes Shell and user auth dialog.

So, this is how all the stuff looked like.

Also the simple Main screen for quick game was introduced that had to look clean and simple on all the form factors

Drawbacks and limitations

Carousel

The first issue I had was with swipe gesture, as it worked only when strictly horizontal swipe was done, so on ios (where you can move the page up or down even if there is no actual scroll ) you needed to be really careful with your gesture.

Game dialog and custom controls, phone screen

The initial idea was to open the actual Game ui inside the dialog so that it would use all the available space and not be visible as a carousel page.

And for this I obviously had to create my own controls.

From my own experience I can say that this part of sdk explains everything you needed pretty good.

So it was not a big deal, and in case you're interested, you can go into the details of controls' code itself.

What I can say is that I really loved how the way two-way binding works for you when you do your own controls.

But the issue was that I soon found out that for some reason mobile jquery mobile had some problems retrieving my controls inside the dialog, so the game became sluggish on the mobile devices while working fine on the desktop.

And another restriction was the screen size estate.

For example, I wanted the medium board to fit the phone screen without horizontal scroll

So I needed to change something there without doing the major refactoring of my stuff.

App redesign and feaures

Also by that moment I understood that I am not doing the remake of the older game, but instead implementing some new stuff.

So most of the older parts of the ui were discarded as well.

There are still some unused fragments that can be found in the code though.

Shell + NavContainer

And so I went back to experimenting.

And it turned out that you can embed NavContainer directly into the Shell, so this would give you an option of putting pages there.

And this way, you can just handle page transitions programmatically, in case you have some limited amount of screens and do not need to pass parameters to controllers through route vars.

So, fast forward to what I have now is this:

This is a 320x480 screen (even smaller than my 4inch SE phone which has 320 x 568), and it almost fits here.

And this is the preview of 480x640 screen

Also the small board fits even the smallest screen in landscape mode

And another feature of Shell that I'm going to use in further development is a sidebar pane which allows you to display some content in a side-by-side manner even on a small screen (screenshots below just demonstrate the approach).

IconTab + FlexBox + Lists based layout

Also it turned out that you can IconTab pretty much everything everything.

And with FlexBox and ScrollContainer it makes a major part of my app design

For example, I use it in Main page fragment to start games:

And I also use it on another page along with Lists with different list items: StandardListItem and InputListItem.

This is how it looks:

But besides those two guys we have at least two list items that I want to mention.

The first one is ObjectListItem.

And it turned out I could use it to represent my objects which were not Sales Orders or Items in Stock )

It has some cool properties and aggregations, so it will probably fit to almost anything you'd like to put on small or big screen.

And in current release with multiplayer support I even combined it with IconTab (remember what I said earlier? ) 😉

Another list item I liked a lot (which you might have already noticed on the screenshots above) is NotificationListItem as it allowed me to display the flow of events with some contextual actions or reactions, as it has a buttons aggregation.

Here I need to say though, that adding too much of those into DOM can impact the performance of your app, so I ended up handling with this list content programmatically (to display only some recent events).

It had some glitches with item width on a desktop so I removed he FlexBox and allowed it to use the whole screen width

Grid issue

Another layout issue I had and which made me implement not so pretty solution was Grid layout.

As you may bind "content" aggregation as any other list aggregations to an object or an array, while using a control or even a fragment as a template, I thought of getting this stuff with an elegant approach:

But instead it made it look like this:

Maybe I just did not spent enough time troubleshooting this, or I am missing some easy solution, but the way it worked for me was a little bit ugly:

But at least this way I discovered a way to directly bind elements in xml view of which I was not aware before. Probably it is just a bindElement there behind the scenes.

Controller stuff and antipatterns

Of course, as it was a quick prototype, and I did not want to use routing and all that stuff, it ended up with a single "Controller as a model" anti-pattern (kids don't do that).

And technically it remains in this state, although I introduced some "kind of refactoring" to it.

What I did to slightly increase code maintainability - was introducing kind of mixins to split a single file into pieces.

So what you do here is just extend the prototype of a Main controller with methods from your "mixins".

But the drawback of this approach was that (probably due to the view-controller lifecycle stuff) mixin methods could not be used in xml views to handle the events, so I ended up with a list of a stubs:

Conclusion

I hope this post will give you some insights of what could be done (or what must never be done ) in your future apps or prototypes.

Probably I missed some other ways of implementing the layouts I needed, but nonetheless I got a feeling that with some trial and error I can get a result from the stock ui5 controls that would fit my needs and would work on any device I expect.

In case you want to know more about the code, please go to github, as all this stuff I have done is opensourced there.

You can also just clone the repo and run the index_webide.html in your webide to play with it.

In the next post I will talk about packaging the ui5 stuff in cordova via vanilla cordova cli and local/cloud HAT.

And also I'd like to thank sap for all the effort they made to provide developers with tools to create stuff like this. And special thanks goes to the phoenix icon which actually inspired me to find some new ideas about the game )

Hope I do not violate any licenses as I use openui5 and its resources in my builds that are submitted to ios and android app stores. Otherwise please contact me to solve those issues.

Thanks for reading this, and sorry for too many pictures.

Feel free to ask any questions, though from the code quality perspective there sure can be done a lot, so it is not something I can be proud of, and instead I consider this as a quick prototype to play with.