My take on an approach of the GUI

Volumio Development Developer's Corner
1

Hi all,

I’ve been reading a lot on here, and comparing it to my different work environments. And I have this following idea. Take it just as an idea

How I see it is quite simple.

My idea is completely de-attach the GUI from the distro. It’s running NodeJS, and that’s the only thing we more or less need.
This schematic is very very simple, but shows exactly what it needs. See “Volumio-seperation-architecture” image.

The idea is to have only NodeJS as the backend for the GUI. It handles the communication between the GUI and the MPD-server. The client we could use for it is mpd for node (npmjs.com/package/mpd). For settings, we could run another microservice in NodeJS.

For the Front end part.

  1. Tooling
    I would suggest using SASS & Gulp as compiler. And without trying to run it locally, why not just at Volumio. Whenever you do an update, you can run an NPM script. When it’s done, it gives a 200 OK, and the browser refreshes. In that case we do not need a build server for the SASS & JS compiling. Gulps is much more interesting than Grunt since it’s many times faster and light weight. Of course, it needs to just load the compiled version for the users.

  2. The GUI
    I think it’s handy to start using one page app. There is no need for different pages. It also makes the UI feels much smoother. We could use libraries like EmberJS&Handlebars / AngularJS or Reactive Extensions. I prefer the last since the technique is very modern and works in a really simple matter.

  3. Handling events / async stuff
    To continue on Reactive Extensions, it might be an idea to use this framework/library. It captures all events and the only thing you do is filter trough it. If you prototype each function (which is REALLY handy with audio players, since they share nearly all the same ways) , you could do something like this.

Artist, Album, Genre, Playlist, etc -> a collection with multiple songs, has prototyped functions like: playNext, playNow, addToQueue
Song -> a collection with only one song: playNext, playNow, addToQueue
Transport Control-> Play, Pause, playNext, playPrevious, RepeatOn, RepeatOne, shuffleOn, ShuffleOff

a html could be
Play album next
Play next song

You can see the possibilities here :wink: Just listen to all events beginning with data-control, reduce whatever you fancy, and filter on the last -album / -transport. Use the playNext etc prototypes as filters, and use a kind of [not implemented] feature.

  1. Independence
    If we structure it easy enough, we could easily develop it on a virtual machine, while checking its functions live on current versions of Volumio. By creating a package.json for node, we can install all the necessary tooling on the VM as it was on Volumio. The integration with the IDE can be run using an external SSH tool.

To distribute the GUI, we can use forks and stage all changes using the following method : see Volumio-gui-distribution-diagram

So again…just ideas :slight_smile:
build.jpg
volumio-seperation.jpg

2

I need to take a closer look to the Reactive Extensions, but in general I think this will fit to the architecture idea and this will add a more flexible and reliable distribution system.

3

I do agree on these:

  • SASS & Gulp for CSS (gotta look at gulp, but if you’re mentioning sass it means you know what you’re talking about…)
  • Angular was my first choice as well. Dunno about Reactive extensions, gotta check this as well!
  • Customized Bootstrap getbootstrap.com/customize/ (gotta decide what to use)
  • Good Old Jquery UI, to make it fancy.

We can start working on it now, if you think so. Open for other suggestions (see other topic, keep current UI or redesign it completely)

EDIT: This may just be perfect github.com/angular-ui/bootstrap

4

I do like the idea of de-attaching the GUI from the distro, this makes it very portable to other devices!
After having a second thought. our whole backend system (aka ‘core’ system) is using services specific for RPi/linux, so it does not make any sense to use the GUI on a device with a distro that does not support these services. You will end up with a GUI and a semi-broken backend system. Users will have to develop their own service-controllers (which is possible thanks to the open-source) but this is not something you want in general.

I think we should still de-attach the GUI from the distro. This will help us porting Volumio to other devices in the future.

I might be missing something, but as far as I know we want to let the GUI talk to our system directly, with its own interface-layer if needed. I do not recommend having it talk to the MPD-server, since this will limit our functionality. Our GUI is something that should be optimized for usage with the system we are using. This will keep the performance high as well.

I like the one-page-app as well. You guys are probably familiar with the Spotify interface (either the app, or web-player), and I think its very user-friendly. You have your playback/navigation stuff available everywhere, and browsing/searching/playlist should probably be pre-loaded as well to keep switching views nice and fast. (I’m no web-developer, so I might be wrong here)

I do not really know how the current update-system works (and if its activated), but this idea looks interesting :slight_smile:

I’m no web-developer, so my posts on this subject may sometimes make no sense :unamused:

5

This could be an idea, but let’s postpone this. First: it takes quite a lot to create an integrated environment that just work, with one system. This is one of core principles of Volumio: offer the simplest experience possible. And this can be achieved only by tying the front end with the backend. Again, this is one of the best features of Volumio.
Imagine to repeat it for, let’s say MacOsX or Android. Just imagine the hassle.
My point: let’s develop the bridge from WebUi to system as a module, so we can easily upgrade it in the future. But let’s to just this, to do it good. This is something crucial for the quality of the project.

Like it as well. The real challenge here is make a one page app responsive, that will work equally good on PCs, tablets and mobile.
I already have some ideas… Guess, we need mockups…

6

Is there a way we can make device-specific GUI’s? Most websites these days have a mobile-version of their website. This might be a lot of work, so lets focus on PC first, since this will be the main for most users, but would it be possible to create multiple versions to support more devices?

7

Actually the process is inverse: mobile first, then bigger screens.
Current WebUI, and the new one I hope are built with Boostrap, a responsive web design framework.
It is quite handy, because you just use responsive layout grids. You can define how items will look in mobile, tablet or desktop views. So, no need to create different layouts for each view: just create a good and well designed one.

getbootstrap.com/css/#grid

8

Ah ok, sounds logical.
Does this mean tho that the bigger screens will just be a “scaled” version of the mobile page? ( scaled in quotes because the size of objects dont actually change)
Because I think we should make a page for mobiles with a different layout, like a slider-page for navigation between views or something. (does this make sense?)
Something like this:

On bigger screens tho (tablets/pc) we can just put that navigation drawer on the main page since theres enough space.
Would this be possible?

EDIT
This is how spotify navigates. Would be awesome to have something alike on our mobile interface. (as navigation ofcourse, rest of layout to be discussed)
Screenshot_2014-12-10-23-42-10.jpgScreenshot_2014-12-10-23-42-14.jpg

9

I personally think that Bootstrap holds a little too much inside it. Perhaps we can use a slimmed down version of it. On the CSS side, I’m a really picky person. Reset classes etc are generating too much. I have to in my current line of work. (Have to optimize for half a million visitors (not page views) a day). I personally vouch for the grid system. It’s quite solid. Using the font-awesome icons can work really well. I really like how they build it.

Since smart watchers are quite interesting, we might be able to start there even. In the really basic way possible. In terms of the Scrum / agile approach; add value fast (but write good code :stuck_out_tongue: ).

The mobile first (perhaps smart watch first ) approach really helps also with designing the most crucial elements as good as possible.

If we can, like Michaelangelo suggested, maybe making the interface layer modular, it’s easier to build the front-end. Even better…we can write tests for it, and automate a development environment for it. I do understand the choice of tying it. I would say… provide a View in the MVC, and we could work on that.

Oh; one more thing… the current UI has a “Stop” button. Do we really need this? I don’t miss it in the Spotify app really. I know these are basic functionalities perhaps of MPD, but in my opinion, they are not needed. The stop button was initially intended for mechanical operated transports, but since most of Volumio players are always on, it keeps at the last played minute.

10

I’m also ok with what you said. Sass & gulp looks interesting! Although I don’t know them, I just hope gulp is flexible enough to let us write some building scripts

About Angular Vs Reactive: here again I can’t say what’s the best since I’ve never used them. What’s pros & cons? Actually, are they really in concurrence, or are they complementary? After some search, I see several examples where they’re used together : xgrommx.github.io/rx-book/conte … EADME.html

11

They stilll need more community support. But we’re working with it for a huge code base and visitor base. Can’t compare it really to Volumio. But a 15 minute build we brought back down in 20 seconds. This includes concatenating, compiling, minifying, cache busting and caniuse support. Pretty awesome stuff. As well, you have to write a lot less than Grunt. We literally can just flip the switch and develop on a working volumio distro :wink: makes it awesome.

I don’t work with any of this myself really. More that just haven’t found the use yet (i’m not building apps, but just pages :’( ). They might work really well together. I have no idea. I really think the Reactive Extensions is a more sturdy approach than Angular. However, they both serve their purpose really well.

Angular allows us to write apps much better and faster. ReactiveE also helps us to write apps, however it uses the map, reduce & filter principles. Which in its turn is great if you’re working with a lot of data collections, like Netflix… or you know… Volumio :wink:. So the principles match really well. I personally believe in matching the principles of framework and use case will provide the best connection. Matter of POV :smiley:

12

Today me and Hooch worked on integrating Angular and Bootstrap on the WebUi part.
I can sayt that Angular looks exactly what we need. We are gonna structure DIVS with controllers, which then call specific functions for this controller. Again, this way we’re making it really modular. Allowing us to associate each views block with their controller.
The advantages:
-Cleaner code
-Modular Approach
-We can define different playback structures and controls for different views.

See this example:
docs.angularjs.org/guide/controller

Angular can be integrated with Socket.io for async server side integration:
html5rocks.com/en/tutorials/ … ebsockets/

13

Then, talking about SASS & Gulp. Now we have vanilla bootstrap on it. But I’m really intrigued by trying those two bad boys.
What do you think in deploying it to the repo and write a little dev guide (and compilation guide) for it?
This would be really useful to get us started

14

They can be really well used together with it. Never had the opportunity to use socket.io. Other than I’ve seen what the power is of sockets (big brother watching in a reverse proxy way :smiley: )

Yhea. I would love to do it. I can start on sunday with it. I can prepare the stuff. Only thing I really would like to know is the working (development) directory and the output directory. Let’s say it will output only one file for CSS and one file for JS? (Unless you want to go for requireJS). However, in an application, i think it as well could be just one.

Thats up to you guys. I dont have a clear overview your ideas yet :slight_smile:.

Which IDE are you using? I might be able to write a little guide on how to use it from the IDE too. Handy to control a wee bit more. Working with PHPStorm myself.

15

I work in Eclipse, there is plenty of plugins. But if necessary I can switch to an other more suited IDE.

16

I would go for one CSS, if possible. But we need to have multiple js files, this will optimize upgradeability and load time. The angular way.

I use Eclipse, as its really nice and complete. Occasionally Brackets for html\php. And notepad++ as general text\code editor.

Did I granted you access to the repo? So you can have an idea of the folder structure and the way we implemented bootstrap. If not, tell me your github account and I’ll add you.
If you can contribute with this that will be really helpful!!

17

Im going to download Eclipse, see what I can do :slight_smile:

I’m added to the repository of Web-GUI i think. my git account is jhoutman.

I’m going to do my best :smiley: pretty curious how you guys approach it.

The Javascript files can be also just concatenated into group files. But those are things we can do whenever we need. No biggy :slight_smile:

18

Yes, you’re added. Let me know!

19

I’m currently working on the SCSS structure and adding Gulp. I’m integrating it into a folder directory and let the stylesheet and stuff parse it to the public folder. Same for javascript, so we can use the uncompressed versions which make more sense when developing.

Going well so far. Unfortunately, the run instructions for the GUI didn’t work out really well in the repository on Git. I’m checking what happends with it.

I never worked with Eclipse, but I will write a short explenation how to use the SASS compiler. I’m adding multiple scripts that can be run separately. But in general, all should be fast enough for the whole nine yards :wink:

20

Unfortunately some delay. There’s an issue with node-sass and gulp together. It seems different on each system. i hpe I can fix it today and put a new pull request up.

– uopdate – it works… seems I’ve been trying to put the version number of the wrong package instead :smiley:

Working on the structure including the parsing of SCSS right now. So far so good.

Integrated font-awesome, most of the things work. However… the gulp-watcher works better than the production-compiler script. I need to adjust it, since it gives a really vague error. In the end, it needs to compile to one css file. Which is doesn’t yet.