Luci Gui improvement needed

I personally don't have a single-word description.

I am an IT consultant so what I learn, I use to help clients.

I would consider something like woodworking, restoring old automobiles, or painting a hobby, since I don't do any of those professionally.

1 Like

That's exactly my point. I did follow the instructions step by step through command line and it still doesn't work. How do I troubleshoot? I went to Luci UI to see what's going on and it was no help. Professionals (specially IT) have a delusional mentality that if it's easy for me then it must be for everyone. It seems LEDE is gear toward this niche of high technical pros.

@JW0914 It's not the step by step that's hard. It's what to do when something isn't working. When you don't know something, if it doesn't go exactly right. People freakout, specially with routers because you might brick it. I was giving my experience with LEDE and expressed it with the community, however I felt attacked because you don't feel like Luci needs any improvement and everyone should just learn CLI and shut up.

Luci could be improve to help a lot of other users that wants to migrate from other firmwares. That's my opinion.

Thanks!

1 Like

Not all IT professionals...so your statement is a result of simplistic thinking.

However, as you mentioned, OpenWRT/LEDE is not geared towards beginners, and by its design, never will be.

Sort of like Linux will never be Windows...both are operating systems, and that's where the similarities end.

Likewise, comparing Shibby Tomato or DD-WRT to OpenWrt/LEDE is comparing apples to oranges.

All are router firmware, but much different in design and implementation.

All of us were newbies at some point. Over time, hard work, study, and experience changes that.

I would suggest learning some basic troubleshooting skills.

You would be surprised how well that will serve you in most any problem solving situation.

You have to learn to walk before you can run.

My friends, who refer to wiki an documentation in regard to LEDE configuration, please understand @Bender and all of us that agree with him.
Basic is good, but we came to LEDE for expandability and trust in evolving.
As the title of the topic says "LuCI GUI improvement" is about how LuCI could be friendlier to non-technical users, at the sectors that these users would mostly like to add functionality (NFS, VPN, DDNS) and in a way that would neither add trouble for the developers nor make the OS very large.
Wiki is very good, but some of us can only take feedback of what we did by CLI, looking at LuCI for the results accomplished.
Another example is that we cannot flash another OS by LuCI, e.g. amod or even stock firmware.
Also in System>Software if you are at Installed Packages you don't see the size, if you are at Available Packages you don't see which is already installed, although I think the 2nd would add complexity to the coding, as also showing dependencies probably would.
In Transmission I have to read the Wiki to set the default config_dir and allow me to say that it is not crystal clear. If I remember right, LEDE and OpenWRT documentations where a bit different, not sure.
I love Linux for many strong reasons. I firstly installed Ubuntu 9.04 but I followed a guide suggesting partitions, bloated my boot partition after some kernel-upgrades and abandoned it, because nowhere was clear that if you do not sudo apt-get autoremove you are finished. I came back with 10.04 and stayed. Even now there is not a GUI autoremove kernels in Ubuntu!
No one demands developers to work for us, we also thank them very much for the efforts! It is just that some job that is done in the LuCI GUI anyway, probably could be done in a way that people stay with LEDE. Also some in terms in LuCI acronyms could be avoided, I think.
The key-word about an ideal LuCI is self-explained (where it can be).

Thanks again. Viva LEDE developers!

I would argue that OpenWrt/LEDE is not for "non-technical users"...

You can certainly learn to configure and use it, but you will be disappointed if you expect the ease and simplicity of stock firmware.

2 Likes

To let this discussion here lead anywhere we need to figure out actionable items and, more importantly, find people who are actually going to execute these changes.

Things like "LuCI is not intuitive" or "VPN setup is too complex" are too vague to act on, there need to be specific concepts and requirements to start working on such improvements.

Features like NFS or VPN support will use developer time and take up space to implement.

That would be a monumental task. On the download server I can count roughly ~1700 different image types spread of 57 different targets. Most devices require specific modifications to the OEM firmware in order to be able to flash it via ui, in some cases it is simply impossible due to bootloader limitations and other factors.

The installed size cannot be reliably measured since the overlay filesystem performs transparent compression, which makes it impossible to infer the actual flash block usage from the logical file size.

Granted, the logical size could be shown, but that would be no reliable indicator on whether the software would fit or not, likely even further confusing people if reported and used space do not add up.

It also wouldn't work on devices with 16-32MB ram as cross referencing the package indexes requires a lot of memory.

3 Likes

While reading this thread I keep wondering - what is the motivation of a non-technical user without deeper interest and appropriate amount of time to use OpenWrt/LEDE in the first place? Why not using Gargoyle, or Tomato or the OEM firmware? Because it lacks features? Maybe it is the lack of these features that lead to the perceived simplicity?

Exactly - and why would I even do that in the first place? I wouldn't buy a sports car with the aim of tuning it when I neither ever drove one, nor have any prior experience with tuning or even the money required to acquire the proper tooling.

3 Likes

The abundance of articles on the internet about how crappy the stock firmware is, how it is limiting the users, and how it is stealing their information (ASUS' AiProtection is a great example here). OpenWRT is at (or close to) the top the recommended list. Plus it has a great community, and so on.

Feer sells better and that is how a lot of new people are drawn to the custom firmware while the authors of those posts do conveniently forget to mention the steep learning curve and dedication required to succeed here. And most of all, the investment of time.

Exactly what I was saying. The are lots of minor details that are easy to overlook/miss by an non-experienced person and then the recovery becomes a daunting task

I think the first thing is to figure out what the target audience is. If it is techies or someone that desperately needs a hobby, then nothing needs to be done: it is perfect already. If it is to get a doctor to setup a secure home/office router then two things are needed:

  1. A very short list of best supported routers (in several price categories) to choose from without reading though thousands of posts.
  2. A push-button setup for the basic functions that every router provides and also as simple setup of a few basic goodies, that the bloggers praise that OpenWRT can do with ease: VPN, etc.
  3. An upgrade process that can nicely merge the settings.

But this is a ginormous undertaking.

As to the repeated references to doing expert skill based jobs, that's not even remotely a direct analogy to not knowing how to do something in OpenWrt.

  • A far more accurate analogy would be assembly required furniture, of which includes instructions on how to assemble the furniture, much as OpenWrt provides wikis [instructions] on how to do things, in conjunction with man pages for all CLI programs and daemons.

If someone is following an OpenWrt wiki, and has unexpected behavior, it's like due to user error and not following what the wiki is telling one to do.

Where did I state "LuCI [doesn't] need any improvement"? Please re-read what I said

You don't need to "learn CLI", one simply needs to perform steps that must be completed via CLI... there's a distinct difference. (For example, you don't have to know how an engine works in order to drive a car, just as you don't need to know the commands executed by LuCI when a change is saved in order to utilize LuCI.)

  • CLI (Command Line Interface) is not some big, overwhelming, technical thing, and if it's being viewed as such, then one's perspective is, at the minimum, skewed from inaccurate suppositions.
    • All CLI is is what the "I" stands for: an Interface [unix shell] (in this instance, for UCI [Unified Command Interface]), just as LuCI [Lua Command Interface] is the GUI [Graphical User Interface] for the WebUI.

  • Many things are far easier, and vastly more efficient, when done via SSH and since time is being repeatedly referenced, it is usually quicker to do things via SSH than it is via LuCI... For example:
    • Rebooting a router remotely:
      • LuCI: Login via HTTPS => System => Reboot => Perform Reboot
      • SSH: Login via SSH (~3s) => reboot

    • Disable/Enable. Restart, or Start/Stop a daemon:
      • LuCI: Login via HTTPS => System => Startup => Find daemon => Action
      • SSH: Login via SSH (~3s) => /etc/init.d/<daemon name> <action>

  • On top of that, every daemon and CLI application has a help section and man[ual] page, whereas LuCI has only a handful of disparate help sections across a handful of wikis.

LuCI serves a legitimate purpose and has a multitude of use cases, however in regards to expanding it to be all encompassing will likely never occur for at least some of the reasons in the post I link to above.

I had some ideas about this and I posted this a few years ago: https://forum.openwrt.org/viewtopic.php?id=54056
I'll reproduce it here with a few minor updates:

1. A Luci-based guided setup on first run. It would configure the things most people need in a router:

  • set a router admin password
  • choose between router, AP, WDS, and repeater modes (mesh?)
  • configure the WAN connection
  • configure secure wifi
  • configure an isolated guest wifi network (optional)
  • configure QoS (optional)
  • possibly point to the simplified package manager (see below) at the end

2. A basic and advanced mode in Luci

  • Basic mode shows only basics and hides settings that can break things or that aren't used all that often.
  • Basic should also have some help in a side bar or via link (to wiki?)
  • Check boxes to turn on certain features and automatically install the appropriate packages (e.g. QoS, printing, USB storage, SMB, etc.)
  • Simplified status page that just shows connection status, connected clients, and possibly warnings
  • Simplifed log that just shows the most critical info
  • Advanced mode is what we have today, but could use some more help text.
  • Luci apps should be able to take advantage of basic/advanced modes.

3. A simplified package manager

  • rather than the vast list of packages we have available, show the most commonly used ones that have Luci-apps available (QoS, UPNP, vnstat, file sharing).
  • Display friendly names (e.g. Windows file sharing instead of Samba)
  • Use a simple on/off slider to install/enable/start the package (similar to FreeNAS services).
  • Even better would be a guided setup after installation.
  • Advanced mode turns on the full package manager we have today

A nice example of this in a commercial router is TP-Link's new interface used in the Archer C8/C9/C2600. If that's open source for whatever reason, it would be great to just take it (doubtful). There's a simulated UI available on the web here: https://www.tp-link.com/resources/simulator/C2600_Emulator/index.html

Wiki pages and step by step instructions are nice, but the most common things should be obvious or guided. CLI should never be needed for these items. Things that are not guided, but still relatively common should be intuitive (e.g. guest network without instructions). Vendors clearly put more thought into the GUI than the underlying software, so we should look to what they're doing for general ideas.

I wish I had the knowledge to do any of this, but I'm just a user. Hopefully these ideas can be useful to someone that has the skillset and desire to make things better.

The big yellow sign that says:

No password set!
There is no password set on this router. Please configure a root password to protect the web interface and enable SSH.

...isn't a clue???

I understand these things sound nice on their face. But something as "small" as that could cause a programing nightmare:

  • Does the user want a "guest" SSID on the same LAN with a different password or a separate VLAN?
  • And most obvious, will all this software fit on all routers (I had to install LOTS of extra packages to get the features you're describing...and all of them don't exist on all devices)

You do understand that the router itself is based on the UCI, right?

The UCI is accessed in 2 (or 3) ways:

  • The command line
  • The config files
  • Various LuCI scripts

Those routers that can't hold LuCI (which is not a requirement), must still contain the UCI.

It might shock you to know that theres alot of advanced commands in: firewalls, static routes, etc. that can't be accessed on the LuCI GUI.

@lleachii I personally have no problem using CLI, but it makes it much harder for me to recommend OpenWrt to friends and family. Even if I set it up for them, I am then on the hook for tech support too, which is no good. Why bother with a GUI at all if you can't accomplish common things without dropping to CLI? I see no problem with it existing, but it's for the advanced users.

As for the guest network - pick the most common scenario and make that the default from the GUI. Probably whatever is in the wiki now. Someone getting fancier can look into the wiki, forum, CLI, etc.

There are lots of reasons to choose OpenWrt over those other options and they're the same reasons many people choose OpenWrt. It boils down to stability, security, and features, which are things everyone wants, even the less technical users. The freedom part is a bonus that matters to a smaller number of end users.

For me, addressing bufferbloat was the reason I discovered OpenWrt and moved from Tomato. This really was a game changer - no more QoS classification to make VOIP work smoothly. None of the other firmwares have addressed this issue nearly as well as OpenWrt. That alone makes it worth it IMO and there are A LOT of people that can benefit from this alone, but many of those people need things to be just a bit simpler.

I would prefer not to have an Easy Mode, instead I would prefer a quick-start-guide for the main use cases and let people develop the confidence that they can do this on their own.

The quick-start-guide should include diagrams and screenshots to be more welcoming to new users.

To resurrect this thread, I'd have to say I agree with both points (easy vs. learning), however, a project almost ALWAYS succeeds when users have something that is easy to get going on, dependable, and also allows them to have the option to make it their own with mods.

Case in point... Drupal CMS is wonderful for the stability, security, configurability, etc., but it lags behind more popular CMS like Wordpress, mainly due to ease of use... or lack thereof.

For a project to be successful, it has to have a larger following, due in large part to lack of frustration getting up to speed on it.

One improvement to the Luci GUI would be a luci-app interface that queries the current router hardware model, etc., such as what is done on the hardware selector on the OpenWRT website, and firmware version, and gives the admin a quick dropdown list of available firmware upgrade binaries (stable, snapshot, upgrade vs. full install), which could then be selected to allow the desired (and correct for current hardware) download to local computer which will be used to upload from for the firmware upgrade.

This seems in concept like it would be fairly easy to implement for someone who is more familiar with the Luci app templates and interface nuances, assuming OpenWRT provides an API, or allows for a more targeted https query to the hardware selector table webpage from the Luci firmware upgrade page.

I have not done any Luci programming, but would be interested in contributing time to this, if no one else who is more familiar with the systems and developer contacts involved would be interested in making the necessary modifications to the "Backup/Flash Firmware" Luci module page.

Any thoughts?

I feel keeping it simple is better.
Many older devices barely run the current releases by adding extra functionality that is not necessary those devices may no longer be supported

Rigth, but it is not simple now. Precisely what we are looking for is that simplicity

HTML, CCS, JS and others are just text. I do not think that a quick configuration page is very large, we are talking about a few kb.

Absolutely agree. Throughout history, not the best projects have triumphed, but the most widespread ones. I remember VHS (250 lines) vs BetaCam (400 lines). Do you remember who ate who?

After having seeing some questions in the forum I don’t think a “easier” system would make much difference.

The “easy”, “super easy” and “really super easy“ some ask for is kind of no special functionality at all=original firmware.

But as one said in another post a while ago, Linux expect the user to know something or learn how to do something. Some users really don’t want to read or learn.
Linux/Unix as a base only allowes that much to be done in GUI. After that the terminal is needed.

“Success or not”, well this isn’t even a company so it can’t really be successful or unsuccessful and be put out of a market by competitors that doesn’t even exist. In practical terms OWRT is a “free” global hobby. If you want to play then come along, if you want to play with someone else, okido.

IMO even open source software can be successfull or not.
But to measure the success, you need goals: see e.g. https://openwrt.org/about

As far as i know, there is no goal that openwrt should be easy/simple for the enduser.
Or that openwrt should be widespread to a certain degree ...

But in fact, a lot of companies are using openwrt as basis for their own custom firmware which they build an "easy/simple" GUI on top (and a lot of other nonsense).
In exchange for this, you lose a lot of "complicated" features of the pure openwrt.

A lot of opensource project are not "successfull" in the enduser domain. But very successfull in the business domain. I think best example here is Linux itself.

BUT the best thing on openwrt is: it is free and open source.
You can develop the features you want or hire someone who does it for you.
You can even start a business on top of that.
You can decide which feature is "needed".

And for the example of the "available firmware upgrade list" there is e.g. luci-app-attendendsysupgrade which enables you to upgrade the firmware out of luci including all additional installed packages. Switching to "stable, snapshot .." is for now not implemented.