Openwrt as default web LuCI theme

@metai - angular.js alone is not enough, you still need the actual templates and you need to implement the business logic on top of it. Please take a look at https://github.com/jow-/luci-ng - this is the LuCI2 approach on top of Angular without the need for jQuery.

CBI is not some legacy script for input elements but the framework that implements the bidirectional mapping of HTML forms to UCI. I don't really see an alternative to it or do you propose to write custom ad-hoc code for field dependencies, input validations etc. for every single view?

Its an early alpha at best (refering to the LuCI-NG variant linked in my earlier post). I don't know how many man hours it needs to be complete. Probably many as the entire web development ecosystem suffers from severe NIH syndrome.

The very first question I got when proposing luci-ng was why I wasn't using Angular 2 instead of Angular 1, then second was why I didn't use React instead of Angular :slight_smile:

Writing a proper ui is a thankless job I'd say. The powerusers will dismiss it as toy stuff and not really provide support, the end users will argue about styling and the web developers fight about the proper framework to use :slight_smile:

Writing a proper ui is a thankless job I'd say. The powerusers will dismiss it as toy stuff and not really provide support, the end users will argue about styling and the web developers fight about the proper framework to use

I would not be so negative :slight_smile:, people argue about everything, not just UI.
It all comes down to how much you want something done and how good you are at convincing people to follow your ideas.

btw, summoning @steinmb as he said he is a php developer so being in webdevelopment might have something to say here too.

I'm not sure it is a "thankless job". I just see a ton of work to be done for luci2, and usually that's a one-man job until the baseline is established. So it's more of a "lone effort" without a lot of feedback for a long time.

And, coming back full circle, it doesn't have to be a completely revamped user interface for the near future. I don't have a problem with hardcoded HTML templates as long as they don't contain inline markup and are coded to a somewhat flexible, semantic, modern HTML standard. The current LuCI templates would need a good scrubbing, but it's certainly a manageable effort.

I don't know much about LuCi2. And I cannot find that luci-theme-material.
As of now, uhttpd+lua/LuCI is eating a little less than 6 MB RAM when invoked.
I think there's little to do to make it slimmer, even though, on 8/16 MB RAM boxes that would help.
What we can easily win is more effectiveness: fewer mouse moves and clicks.
And, in my opinion, the current default theme is less effective than the "old" openwrt one.
I don't give fanciness a damn, though.

You can try asking on luci's github and see what other luci mantainers think. Luci is still shared with OpenWRT so those on OpenWRT side don't yet know of your offer.

I spent a few hours yesterday to analyze the template structure, existing HTML and what it would take to "modernize" it in a sensible way without immediately breaking everything that hasn't been adjusted to a newer standard. I still believe it can be done.

This is my current baseline for the layout/responsiveness and a first attempt at where I want to land (this is HTML, but a static "lab environment"):

The colors are still preliminary, really all of the layout is. But that's the kind of contrast/simplicity where I would like to land in the end.

And this is it applied it to the current HTML structure, just with a changed header and CSS. This is an actual screenshot of a running LuCI. Not everything carries over perfectly, but it doesn't break. Other subpages look worse, but I didn't really dig into the real meat of the matter, the forms, yet.

... and a first stab at the "responsiveness":

So, yeah, it can definitely be done. Maybe I'll pick this as my "vanity project" until the end of the year. After all, I need something to do on 33C3.

1 Like

I like that (i mean the mockup, the live luci is pretty much window dressing over the bootstrap theme). I'm sure Uqbar will tell you to shrink the vertical space between the fields.

The "mockup" is actual HTML, taken from the actual LuCI output and adjusted to a newer standard, just as the real templates would be adjusted. Both the "mockup" and the "real LuCI output" use the same CSS.

All of this is just slightly more than 200 lines of handcoded CSS, no framework whatsoever, and especially no Bootstrap. If you're talking about the "look and feel", I think the Bootstrap theme didn't do everything completely wrong.

Ah, this is by no means finalized in any direction, it's much too early yet to finetune colors and measurements. Mainly I wanted to see how horribly existing, unaltered LuCI pages break when I apply modern CSS to them. And mostly, they don't. That's important because even if you go over all the default pages, there is just no way you can treat each and every luci-app-* out there.

1 Like

[quote="metai, post:29, topic:412, full:true"]If you're talking about the "look and feel", I think the Bootstrap theme didn't do everything completely wrong.[/quote]It's just that it is wasting a ton of space, especially horizontally. In many places you could have two coloums (or two boxes side to side) and save 10 cm of scrolling.

[quote]over all the default pages, there is just no way you can treat each and every luci-app-* out there.[/quote]Bulk of luci apps are in luci repository on github https://github.com/openwrt/luci/tree/master/applications , a few others are in the packages repository near the package they are a luci GUI for https://github.com/openwrt/packages .
People maintaining packages outside the official repositories are the sole responsible of keeping up-to-date their code, as normal.

Agreed. Although "boxes" and columns present their own set of problems with usability. I'll have a closer look at how pages are laid out anyway. Additionally, I'm not too fond of the tabs either, I'm not a big fan of hiding content from the user.

And those are the ones we should modify, of course. I'm just trying to not completely break the other unadjusted apps/pages so that they at least work in a basic way. If they don't look as spiffy as the "new" ones, that's fine by me, but they should at least be usable, i.e. present all the inputs and still work.

ad "thankless job"
A big thank you to all luci developers!
Luci sold Openwrt to me and made the initial usage a lot easier (if not possible at al). Even with some experience in this area (e.g. I did compile and setup linux based routers, firewalls and secure tunnels in the previous century, a GUI like luci helps al lot.

ad "changes"
From my point of view it is important to have a "luci environment" that makes it very easy to contribute for non-experts.

2 Likes

Looks great man! If you can achieve the dynamic layout of the material theme without all the extra weight it brings, I'd be all over that!

for those wondering about what is this "material theme", see here some screenshots https://github.com/LuttyYang/luci-theme-material

It was included in official repos https://github.com/openwrt/luci/tree/master/themes/luci-theme-material , but isn't available to people on OpenWRT Chaos Calmer as it is too new.

Yes, I've been looking at the Material theme in my evaluation of what to do and what can be done. And I'm a bit torn on what to do.

The Material theme is a huge step towards what a good theme can do. It isn't perfect, and I have a few gripes with some of its mechanics, but it does many things right. However, what it obviously doesn't do is modify the underlying code. And so it has to deal with all the hardcoded things that come in the default page templates, including tables and overviews that still don't really work with mobile.

I guess what I'm asking is whether it is enough to style existing things better or if I (or anyone else) should invest the work to actually modify the templates and make them work better. If you're all satisfied with what luci-theme-material gives you then there isn't much point in refactoring the HTML for, in the end, little gain.

Material theme is still window dressing over Bootstrap (from a user's point of view). It wastes a ton of space for lulz. Cool yes, more useful, no.

The point here is making a new theme that is more concise than current ones (that are all more or less the same with some window dressing). That possibly also works for mobile.

luci-theme-openwrt is more concise and readable but looks like garbage, and imho isn't terribly better at using horizontal space.

You are the one that knows enough to decide if this requires modifying the templates. (I suspect it's required though, given the very similar structure of all luci themes so far)

Quite many of the Luci apps do not define any styles, but simply use the default CBI styles to render config settings to html pages. But some of the core apps (e.g. firewall) and modules (luci-base and luci-mod-admin-full) define tables widths etc.

We should not do such changes to the existing apps that the current themes break. So, the possible changes are mostly limited to the theme itself. (Or alternatively, all themes need to be fixed/changed at the same time.)

One approach that you could consider is "fixing" Material. LuttyYang has not done much development with since the initial import. I tested it rather extensively in late 2015 when it was imported to the Luci repo and he fixed most of the spotted problems ( https://github.com/LuttyYang/luci-theme-material/issues?q=is%3Aissue+is%3Aclosed ), but there has not been commits from him since February 2016: https://github.com/openwrt/luci/commits/master/themes/luci-theme-material

Material theme is still window dressing over Bootstrap (from a user's point of view). It wastes a ton of space for lulz. Cool yes, more useful, no.

For mobile users it actually offers value, as it is responsive to a large extent. For desktop users with big monitors, there is no such obvious benefit.

I like luci2 but it did'nt complete. I am developing luci2 with react. I try soon to show demo. ( Libray : react, react-router, redux, material-ui, redux-form, react-redux-router).

@iambanh2 - why couldn't you just help finishing the Angular aproach?
Don't get me wrong, I appreciate any work being done on a modern ui but this is exactly the nih case I talked about :smiley:

Not really a 100% front end developers, but there are things to these kind a discussions that I have seen before. These are boring points but perhaps a little sobering.

  1. Security.
  2. It should be mobile first. Add bells and whistles to higher resolution as they come.
  3. Decide if anything in the UI should work if the client do not support js. WACAG 2.0 I think there should be some usability added to the default LEDE UI.
  4. Speed is tricky. Due to more powerful clients have we been able to move more of work load from the server to the client (browser). Nothing is faster then your own handcrafted HTML and js though it is time consuming and you have to handle all security by your self.

Base theme. There is a can of worms. All claim to have invented the perfect layout system. All that jazz. The problem for a project like LEDE is relying on any of them to stick around for a long time. A lot of them are driven only by a few (mostly one) person and not a real project. I think a project like LEDE should be careful relying to much on smaller project that might just stall out. The web move very fast and it is card to keep up with it.

JS framework often have all of the problems above and developers move in/out based on what is currently the next cool thing to do. Makes is difficult for projects with longer time span bundle it as a core feature.

I have to answer in generic terms then I not sure how the front end communicate with the core (rest of LEDE). Pointers to the code that do this?