I just added a task re us choosing a design framework/component lib in the Vue space.

Personally we've been focusing on Vuetify @radiorabe lately so for me that is a prime candidate. Are there any other preferences out there? Is Material fine or do we need something with less structure/more control?

I like Vuetify, I've used it before. I do suggest we try match the existing style as closely as we can without having to create custom elements. For example use the dark varients of Vuetify elements, etc

If there's still time, can I put in a vote for Bulma? It's a gorgeous Bootstrap alternative that is based around CSS (no JavaScript included).

Now that I'm looking at Vuetify, those table add-ins look amazing (albeit very "Google"). I was thinking we were going to try to use DataTables again and try to do the rest from scratch but those color and date pickers are winning me over.

That looks great!

@paddatrapper Thanks! I've been thinking more about a redesign of the interface itself to go more with the framework we're using. Based on my tinkering, it's going to be hard to make it look the way it is now; we'll be fighting Vuetify the entire way.

I prefer paper to design apps so I sketched out what I think we should do next. The first is a more bootstrap-oriented microsite, with the station name, description, website, and social media links up front. The login page would be replaced by a login form on the main page hiding in a dropdown.

The main interface is inspired by an email client, but to have the "email picker" part on the far right. From left to right: navcol with icons, library browser/calendar/settings/etc pane, clock/status/source picker/current playlist (current dashboard) pane. This will allow us to have a place to put in live assist buttons instead of needing to create a new space. It also make it so current playout can be controlled from any page.

I like the design. Though I think I need to work with it a bit before I can give any feedback. My concern about changing the interface is that, during the transition, there are going to be two very distinct visual styles depending on the page that you are on. That puts a lot of weight on users who may not be very technically minded

Indeed. It is a large change. I'm still not entirely sure how we're going to migrate from PHP to Node frameworks. Such a change would be more for switching UIs completely, such as going from Libretime3 to Libretime4.

I still would like to update the microsite, if I can figure out how to do it in PHP. It definitely needs a facelift.

Question: Is the goal to create a static web app that makes API calls (meaning we would only be serving HTML, CSS, and JavaScript from the web server)? Or will a server-side runtime still be needed beyond the Django instance for the API calls?

Yeah. Ideally it would involve migrating the PHP to Javascript and Python and mimicking the look and feel of the current site, but I don't think that will work very well. So I think we should maybe try get things similar to the current site on the new pages as we implement them. Alternatively we accept that there will be a very different look-and-feel and we build new pages with a new design in mind. Honestly I think it depends on how long we thing the migration will take.

We will still need some server side components to interact with Liquidsoap, etc, but that would happen from the Django code in my mind.

I noticed the interface uses the Bootstrap 2 framework, so to keep the interface consistent, we should consider sticking to Bootstrap. After messing around with Vuetify, I've concluded Bootstrap is much easier, but that's just me.

In the meantime, I'm looking into migrating us from Bootstrap 2 to Bootstrap 4. Upon switching scripts, a ton of things broke, which is annoying but gives us a chance to clean up our CSS styling. I'll post screenshots once things start to look decent.

Update: trying to turn the microsite into a Vue instance.

Hey, I was present on the last Jitsi meeting, but I didn't really show up, as I was sick at the time. But I'm glad to see things moving towards Libretime 4 and I would like to help !

I'd prefer using bootstrap over material design, for more control, and less material design 😄
I think using Storybook is a great idea, we should really consider it.

Regarding the future front-end framework, I would like to suggest few points :

• We should use Vue3 instead of starting with Vue2, migration might not be especially hard, but Vue3 comes with a lot of good things. And hence Vue 3 is almost stable (by the end of 2020), it should be prioritized anyway.
• We should use Typescript instead of JavaScript, it will bring a lot of benefits (requires Vue3) and learning curve is really not that steep.
• I would push for boostrap5 already but maybe we want to rely on some Boostrap+Vue framework that handle all the Js logic already. But that seems to be a problem, since such tool does not support Vue3 or Boostrap 5 yet. Also since oostrap 5 drops Jquery, we could use vanilla JS instead of relying on some extra binding tool, but haven't looked into this at all.

Regarding the micro website, I wonder how much of us really uses it ? I feel this put Libretime in a 'do it all' place, and instead of a micro site, some API calls with a Javascript SDK might be better suited for creating a public website.
Any way this is a complete other topic.

EDIT:
And what devices are we targeting ? Should the new front-end be fully responsive ? I would prefer not having people editing the broadcast timeline on their phone, but maybe create a read only panel that summarize some key information ?

@jooola I completely agree with a lot of your points. Some thoughts:

• The reason for reverting to Vue 2 was @paddatrapper and @hairmare recommended using Vuetify (a UI design framework, like Bootstrap). Vuetify don't work with Vue 3 just yet. Using Bootstrap would let us keep more similarities to our current interface.
• Bootstrap 5 looks great but part of our aim is to slowly migrate PHP to Javascript still being served over PHP, meaning there would be an overlap between old code and new code on the stable (albeit Alpha) releases. I personally would prefer legacy while we migrate. Besides, as I mentioned previously, most of the current app is based off Bootstrap 2.
• The microsite seems kinda bleh... I feel like it's one of those extra things we're putting effort into that a) isn't a selling point for Libretime and b) other services do better already. Especially since we're having issues with HTTPS, it doesn't really make sense have Libretime be an exposed service instead of a back-end service that serves front-end websites using widgets. Ditto for the podcast publishing feature.
• I don't think we're targeting mobile phones and tablets for programming shows, but it would be nice to have an interface that works on smaller, 11" laptop screens.

Also:

I feel this put Libretime in a 'do it all' place, and instead of a micro site, some API calls with a Javascript SDK

@paddatrapper is working on a new API in #958. I'm not sure if he's specifically working on a JSON API, but definitely put in a feature request. 👍

I'm thinking of replacing the microsite with a login page that looks like the Nextcloud login page with space for a logo, maybe a background image too but we already have logic in place for inserting a logo:

Django Rest Framework as being initialized in #958 will expose the existing data as a JSON API.

An additional reason to still use Vue2 rather than already use Vue3 is that VueI18n doesn't work with Vue3 either. Upgrading from Vue2 to Vue3 will be easy if we take care of any eslint warnings.

Is BootstrapVue the way to go if we decide to base the new Frontend on Bootstrap? It's still based on Bootstrap4 as far as I can tell. How hard is updating major Bootstrap versions? The nice thing about Vuetify is that it comes with much more batteries included compared to Bootstrap. The latter being more of a CSS framework while the former also contains complete fronted components that also contain frontend logic.

All in all I would expect the LibreTime4 frontend to feel similar as the current UX. Personally I don't think we have to make it match the currently layout in a pixel-perfect fashion. As long as the navigation and views are recognizable to current users I think this should work. IMO modernizing the UI is also a chance to make lots of it look more 2020 than the current look.

As part of implementing the strangler pattern I am thinking we will want to make Vue components available in the existing frontend. This would make it possible to already start using components w/o replacing everything in one big change.

I am very much on board with getting rid of the micro-site. Given that there have been a considerable amount of feature requests and questions regarding the micro-site it looks like we would want to offer some kind of replacment for it. I'm mulling over implementing a Wordpress plugin that could offer some of the features folks expect form the micro-site.

Regarding the refactor to TypeScript... I'm not a big fan of TypeScript personally. Using modern JS and eslint addresses a lot of the concerns that TypeScript can take care of w/o introducing a new transpiled language.

I second @hairmare about Typescript. JS has come a long way recently and with a good linter I think you don't have to worry about many of the things TypeScript seeks to solve. Further using JS ensures that the maximum number of people can contribute to LT without needing to learn another programming language to do it.

In terms of BootstrapVue, there is no ETA for Bootstrap 5 support: bootstrap-vue/bootstrap-vue#5507 (comment). They are also talking about a complete re-write before that happens, so I don't think it will be soon. Vue 3 and Bootstrap 4 will be supported soon (hopefully).

On the Vuetify side, Vue 3 support is slated for Q1 2021, but I'm not sure how close they are to that, the issue board is still long: https://www.notion.so/d107077314ca4d2896f0eeba49fe8a14?v=121b5e46b07246aa8d26f7f89cfefce4. I also like how Vuetify comes with batteries included, as it means less time re-inventing the wheel. However, the flip side is that it is difficult to customize to look similar to our existing look and feel.

Overall my concern is if Vue 3 is a large change from Vue 2. There are several nice guides around and looking at https://dev.to/blacksonic/the-vue-3-upgrade-guide-4dc4 it appears that the changes are fairly straightforward, though with many components becomes tedious.

For the micro-site, there do appear to be quite a few people using it. A WordPress plugin replacement could be sourced from these: https://discourse.libretime.org/t/onair-wordpress-plugin/718/7

If we were to move the Libretime interface to IP/libretime, and then provided a microsite template for stations to implement as an HTML theme or Jekyll theme, do you think that would be sufficient to help stations migrate away from our microsite?

IP/libretime?

Like 192.168.0.23/libretime/. Moving the interface to /libretime/ instead of /. Does that make sense?

Ah, no I don't think so... I think the selling point of LibreTime is the automation and management, not the microsite. The site is just a extra feature that means that smaller installations do not need to run a second server with a website, they can just install and have everything work

Sorry, I don't think I'm making sense.

Currently:

/ -> microsite
/login -> login
/calendar -> calendar
# etc

I'm suggesting change to:

/ -> left open, so stations can put their website on the same server
/libretime -> either login page or redirect to dashboard, can also be SPA
    /dashboard?tracks -> tracks view on dashboard
    /calendar -> calendar
    /streams -> streams redirect of `hostIP:8000`
        /airtime_128 -> default stream
# etc

Does that make more sense? This would turn Libretime into an SPA that can be added to the same server as the station's website, with API calls talking to Liquidsoap, the database, and friends. Libretime would be able to be dropped onto the same server as the station's website. Furthermore, I can put together a HTML5/Jekyll theme and instructions for stations to deploy it at / on their server, thus taking away the need for microsite.

That makes sense, but I think I would rather leave LT on / and let stations use a reverse proxy if they want something different. They could also use a sub-domain for LT and host things on the same server. The larger issue is that all these solutions require the person deploying LibreTime to have more knowledge of Linux and other systems. It takes having a working deployment from running a script to running a script, installing a webserver, building a website and configuring the web server to serve the website

Since we've been talking about removing the microsite and podcast publishing feature, I was thinking of removing the podcast player tab on the microsite, replacing it with a link to an RSS feed to subscribe to in your podcast player of choice. It's a much more mobile-friendly move and leaves us with one less wheel to reinvent. @hairmare @paddatrapper @jooola hoping for feedback before I start working on changes.

Sounds good to me. The podcast feature doesn't work at the moment anyway...

This issue has been automatically marked as stale because it has not had activity in the last 5 months. It will be closed if no activity occurs in the next month.
Please chat to us on the forum or ask for help on our chat if you have any questions or need further support with getting this issue resolved.
You may also label an issue as pinned if you would like to make sure that it does not get closed by this bot.