[Make-wifi-fast] [Cerowrt-devel] arstechnica confirms tp-link router lockdown

[David Lang]

On Sat, 12 Mar 2016, Jonathan Morton wrote:

quick note, your quotes mixed things I said with things Alan said

>> But the biggest barrier is probably that the web interface is
>> cluttered with features you don't need, so there's a setup wizard you
>> go through once, and you don't touch that even if you're curious
>> because you're at risk of resetting it.
>
> That’s a good observation, and suggests a design principle to follow in future.

I think this is a significant factor.

>> Just because they screwed up the WNDR3800 with too many different
>> coloured lights, it doesn't invalidate the principle.
>
> It’s not just the WNDR, and not just Netgear.  Every router I’ve seen has too many lights which provide too little information - and even I have to squint and read the manual to figure out what it’s telling me.
>
> Except Apple.  Then you have *one* light which provides too little information - but at least I don’t have to read the manual to figure it out.  :-)

some of the lights are fairly obvious, others less so.

>> You have a much larger display, which gives you room for help text and images, not just a handful of characters.
>
> You might assume that I’m thinking of a 16x2 character display.  I’m not - that’s too small to be user-friendly.
>
> Rather, something like this, which gives 128x64 pixels (equivalent to 21x8 characters with a 6x8 font) and the freedom to draw icons and choose fonts:
>
> 	https://www.adafruit.com/products/250

a 6x8 font on a 2.7" screen is unreadable for many people, this is about an 11pt 
font on something that is not at your optimum reading distance.

> There are also small OLED displays which give a sharper, higher-contrast readout, but these are more expensive, lack the capacity of colour-coding anything, and appear to be so small that some people might have difficulty reading them despite the sharpness and high contrast.

OLEDs do color as well.

> The original Macintosh put a whole desktop environment on a tiny (by modern standards) 512x384 mono display.  We don’t even need *that* level of sophistication.  I’m confident 128x64 mono will be enough if carefully designed for - it is substantially more than a classic Nokia phone provided.

don't ignore the DPI, it's not just the number of pixels, it's the size of the 
resulting characters.

>> A display is nicer than just LEDs, but it's also a lot more expensive.
>
> Yes, it looks like a decent display+controller combination is more expensive than a mini-PCIe ath9k card (even discounting the markup associated with Adafruit providing a maker-friendly kit rather than raw devices).  It will therefore be a significant contributor to the BOM cost.  This is justifiable if it also contributes to the USP.  On the upside, with a status display we can reduce the number of LEDs and associated optical channels, perhaps all the way down to a single power light.

don't forget that you also have to have buttons/switches to go along with the 
display. don't assume that people are going to have a spare USB keyboard around 
to plug in.

There is a substantial population who's only computers are tablets, phones, TVs, 
and other non-traditional devices, but who need wifi to use them.

If I'm going to drag out a full size keyboard, I sure don't want to be trying to 
squint at a 2.7" screen.

>> I also don't like large glowing displays on devices. I frequently put tape over the LEDs to tone things down as well (especially in bedrooms)
>
> An RGB LED backlight can inherently be dimmed - and this could occur 
> automatically when out of setup mode (keyboard disconnected) and the overall 
> status is OK.  Also, since it illuminates a relatively large area, the colour 
> can be discerned without high brightness in the first place.
>
>> I don't know if you really can simplify the configuration the way you are 
>> wanting to, but I'd say give it a try. Take OpenWRT and make a configuration 
>> program that you think is better.
>
> Yes, I probably should.
>
>> You even have a nice browser based tool to start with (luci). If you can make 
>> a browser based tool work well, then if your tool is better/easier, it can be 
>> widely used, or you can then try hardware versions of it.
>
> Since the entire point of my proposal is to get away from the “web interface” 
> concept altogether, and I have an allergic reaction to “web technology” such 
> as JavaScript (spit), that’s *not* what I’m going to do.  Instead, I’ll 
> prototype something based around an emulation of the display linked above.
>
> But I will take a careful look at Luci to help generate a requirements checklist.

my point is that you can use a browser interface to mock-up what you would do on 
your local display without having to build custom hardware. Yes, it would mean 
you have to work with javascript/etc to build this mockup, but it would let you 
create a bitmap image with buttons/etc that will work the same way that your 
physical device would, but be able to tinker with things that would require 
hardware changes if it was a physical device (different screen sizes, button 
placements, etc)

Then if you get an interface that you think is usable, others can test it as 
well, again without having to build custom hardware.

Once you get a working design, then you can talk about custom hardware.

David Lang