Browser independent pages...

[Jasen Betts]

On 2023-06-12, Don Y <blockedofcourse@foo.invalid> wrote:

On 6/11/2023 11:11 PM, Jasen Betts wrote:
On 2023-06-11, Don Y <blockedofcourse@foo.invalid> wrote:
What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

HTML (perhaps you should say what you really want).

\"The most browser independent toolkit in which to design pages\"

There are many UI toolkits available for designing pages.
Most are built on javascript.

That dependency limits which browsers will be able to
correctly render the resulting pages.

Similarly, HTML exists in many versions. Designing for HTML5
means a browser built prior to that won\'t be able to render
the pages (it simply won\'t understand the tags).

If you need to support client devices with browser software older than 10
years then yeah HTML 5 should probably be avoided.

Dimiter\'s suggestion (GIF w/map) could be wrapped into a
toolkit that supports more advanced widgets/controls:
- scrollbars
- text boxes
- radio buttons
etc. by creating graphics that are pasted (server-side)
into the served GIF and interpretting clicks mapped into
the associated control at the client and directing server-side
routines to modify the GIF accordingly.

I\'ve not found such a beast -- yet. And, it could be that
HTML evolved faster than the perceived need for such a
toolkit.

You\'re using buzzwords like \"toolkit\" without defining what you
mean.

But, I can use that technique to achieve the results I seek;
it\'s just more of a manual process (akin to using Xlib instead
of Xt/Xaw)

That seems like a hard way to achieve a poorly defined goal.

--
Jasen.
🇺🇦 Слава Україні

 

[Don Y]

On 6/12/2023 12:57 AM, Jasen Betts wrote:

On 2023-06-12, Don Y <blockedofcourse@foo.invalid> wrote:
On 6/11/2023 11:29 PM, Jasen Betts wrote:

The goal is to use the EXISTING browser (whatever it may be) as a
remote-frame-buffer-with-pointing-device interface. And, not to have to
install something
to get that capability.

possibly \"noVNC\"

https://novnc.com/info.html (mozilla public licence 2.0)

Perhaps you missed:
\"And, not to have to install something to get that capability.\"

no. I saw, and believe, I understood that. However you cryptic posts
are always short on the essential details, and I\'ve had enough of this
thread.

Don\'t let the door hit you in the ass on your way out!

Hey, why not save yourself the hassle and just add me to your killfile?

 

[Don Y]

On 6/12/2023 1:02 AM, Martin Brown wrote:

\"The most browser independent toolkit in which to design pages\"

There are many UI toolkits available for designing pages.
Most are built on javascript.

That dependency limits which browsers will be able to
correctly render the resulting pages.

Bare bones HTML4 and a limited subset of CSS might do what you want.

Anything that I rely upon will be something that I will also have to
*implement* in a \"UI device\".

If, instead, I limit myself to only the barest of essentials to put
images in front of a user and get feedback from him, then I have less
to do, less to troubleshoot, less to maintain.

There are protocols that I could use (RFB, ALP, etc.) but that means
I can only use devices that already recognize (and implement) those
protocols. I can\'t use a device (cell phone, TV, game console, etc.)
that doesn\'t include that sort of support.

Web browsers, OTOH, seem to be ubiquitous. But, in varying states
of support. How many versions of your browser have you had
installed on your XXXX over the years? Could the *first* browser
display every page you encounter, today? Could those pages have
been built in such a way that it *could*?!

So, find the least set of capabilities that I need to do I/O and
then build on that. Replicate that (and only that) in my UI devices.

Server side includes and scripts on the server might also allow you to do what
you want if they are permitted. They can also be easy targets for malware
attacks I see a lot of PHP and Perl script injection attacks (so many that I
catch them and return an apparent but fake Unix prompt).

Otherwise the 404\'s from the bad guys clogs up the logs making genuine missing
content faults or links that have vanished much harder to spot.

The server (and clients) are not externally accessible. A logged error
would mean something is broken.

Similarly, HTML exists in many versions.  Designing for HTML5
means a browser built prior to that won\'t be able to render
the pages (it simply won\'t understand the tags).

Tough. If you value your sanity insist on one of a very few common browsers on
each platform you intent to support. The browsers on mobile phones can be
particularly fickle about how they behave on some sites.

But, how much of that is related to the unconstrained nature of those sites?
The fact that the designers opted to use different tags beyond a core set
of \"basics\"

I\'ve not found such a beast -- yet.  And, it could be that
HTML evolved faster than the perceived need for such a
toolkit.

Every professionally coded large scale website I have ever looked at in detail
seems to have roughly half the coding there to deal with browser quirks and
irregularities. Some of them are truly horrid to look at!

Again, because you\'re trying to make a bunch of different (make/model/version)
browsers all render the same content in an equivalent way. And, trusting THEM
to do the rendering. It\'s akin to the terminfo database with glass tty\'s...
how can you ensure what the user sees will be the same regardless of tty
he\'s using?

If, instead, you can push an *image* to the device, then YOU can build the
image to appear as you want -- the client doesn\'t have to do any rendering,
doesn\'t have to support a variety of different controls and tags, etc.

If you have a short, fat pipe -- and surplus resources on the server
side (and only one or two clients) -- then this isn\'t a problem (web
sites have to tolerate an unconstrained number of clients, each
with potentially different browsers, operating over different distances
and delays, etc.).

Think: Sun Ray. Or, at the more abstract end, an X terminal.

That ship has sadly already sailed. The browsers are what they are and reliable
or standardised are not things that they do well.

But, only if you want to use the full complement of features available
in the language (and augmented by client-side add-ins).

No, we don\'t have to be able to process 10 different image formats.
Or audio formats. Or...

But, I can use that technique to achieve the results I seek;
it\'s just more of a manual process (akin to using Xlib instead
of Xt/Xaw)

PNG with palleted colours offers better compression than GIF if you decide to
go down the image map route.

I wasn\'t thinking of using compression at all. Short, fat pipe. Make it easy
for the server and client. Treat the interface as just a dumb extension cord.

The big problem now is that there are mobile phone screens with high resolution
screens almost the same as big PCs but touching menu items that have been drawn
to scale on them is completely impossible and some (most?) sites don\'t render
zooming in at all well sometimes at all!

The user can\'t be required to invoke a magnifier. The page has to present
in a usable form.

But, you\'re not designing generic web pages. Instead, you\'re designing a
control panel for a *device* -- except the control panel is remote from
the device. And, you are aware that it will exist in physically small
versions so you wouldn\'t cram lots of controls on a single page.

Similarly, a \"browser window\" on a PC could be arbitrarily small; you\'d not
want to have to scroll around to find dozens of controls that were placed
on the page thinking it would be rendered large.

In years past, I\'ve used PDAs for this purpose. So, a user could approach
a piece of kit and interact with it via a handheld display/keypad (stylus)
instead of having to put controls in what might be a nasty environment
(wiping grease off a touchscreen is not how folks want to think of your
product; nor do they want to be restricted to big, hermetically-sealed
knobs and the constraints those place on information interchange)

But, these picked *a* PDA (not that there were hundreds to choose from)
because there was no standard \"communication format\" that they would all
interchangeably recognize. That\'s no longer the case with browsers
everywhere.

EXCEPT, you can\'t just pick an arbitrary level of \"support\" on the
client side -- well you could if you want problems! (but, there was
NO \"client side\" support in the PDA approach -- beyond the actual
hardware -- and it worked delightfully well).

I would like a more abstract/automated set of building blocks in a
UI toolkit beyond what I had to MANUALLY create \"back in the day\".
Given that most controls have well established appearances and
modes of operation, it seems like you should be able to \"can\"
their (parameterized) implementations and just graphically place
them on a virtual display much like in Dreamweaver. And, spit
put client and server side instances of that interface.

E.g., a scrollbar is a rectangular region (typically high aspect
ratio) oriented vertically or horizontally with controls on either
end to indicate the user\'s desire to move in the associated
direction. So, you need the overall dimensions of the control;
the dimensions of the controls on each end, a graphical depiction
of those, some parameters affecting appearance (color, bitmap texture,
etc.) and then a position on the page.

Once you have this, you can figure out where (on the page -- map!)
the controls are located and tag clicks in those areas accordingly.
Server-side, receipt of one of those tags would run code that
effectively scrolls whatever the scrollbar is attached to. In
the GIF+map approach, that causes another GIF to be created and
returned to the client.

If you remove client-side processing from the browser, then that\'s
really all that is happening in ANY browser -- adjust the display
to reflect the actions of the user (any other server side actions
are only as visible to the user as the application deems appropriate).

As this is such a common sort of interface control, classes already
exist for it ad pages with scrollbars inevitably rely on those
class -- delegating the rendering of the control to the client.

[If you designed an instrument with a graphic display ON
the instrument and didn\'t go the client/browser-server route,
your \"server\" would have drawn the scrollbar. As *I* will!]

 

[Dimiter_Popoff]

On 6/12/2023 3:30, Don Y wrote:

On 6/11/2023 1:48 PM, Dimiter_Popoff wrote:
....
What I suggest is indeed the most rudimentary way of doing it; you will
do a tiny html envelope for the gif you generate (no sizes etc. need to
be mentioned, this will potentially cause browser independence loss);

Why wouldn\'t I want to declare a size (pixels)?  I would know it as I would
generate the GIF and the HTML...

Some (most? all?) browsers will start to scale your image to the
specified size and thus blur it etc. If you don\'t specify any size
the browsers will go 1:1 pixels, there may be hard to find exceptions
but I don\'t know of any.
And if your screen is too tiny (phone) doing the simplest of html
\"<img>\" thing will let you just stretch the image with two fingers.
Alternatively, you can listen to how the browser announces itself
and do say 4 (or even 9) pixels for 1 etc. at your (server) side.
Martin Brown said something about png instead of gif, if link
mapping works with these on old browsers this is not a bad idea.
Not because of compression, bandwidth is not such a huge issue
nowadays for that sort of app, but because of the colours. gif
allows just 256 - plenty for your purpose but if you can get
more (without compromising compatibility with older browsers)
why not.

if the gif is larger than the window any browser should be able to allow
you to scroll it etc (you might need that for large directories,
vertically).

Yes, exactly.  No need to have a scrollbar widget *in* the HTML.

Probably avoiding any widgets and that sort of thing like the plague
is a must, the gif approach makes sense only if you want to be
say 20+ years backward compatible. Just ancient html.

Otherwise you can even supply a link to cause the browser download from
you and run realVNC, they have a set of files for that IIRC (I did
investigate that some years ago but I abandoned it as customers
were just happy to install realVNC on its own).

 

[legg]

On Sun, 11 Jun 2023 06:32:45 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

Use the old HTML composer from netscape?

Still included in Mozilla Seamonkey.

RL

 

[Don Y]

On 6/12/2023 4:22 AM, Dimiter_Popoff wrote:

On 6/12/2023 3:30, Don Y wrote:
On 6/11/2023 1:48 PM, Dimiter_Popoff wrote:
....
What I suggest is indeed the most rudimentary way of doing it; you will
do a tiny html envelope for the gif you generate (no sizes etc. need to
be mentioned, this will potentially cause browser independence loss);

Why wouldn\'t I want to declare a size (pixels)?  I would know it as I would
generate the GIF and the HTML...

Some (most? all?) browsers will start to scale your image to the
specified size and thus blur it etc. If you don\'t specify any size
the browsers will go 1:1 pixels, there may be hard to find exceptions
but I don\'t know of any.

But I would deliberately draw (render) the image AT the size (resolution)
of the client\'s display. The whole point of this is to take effort
(and responsibility) out of the client\'s hands.

E.g., I use some MSSurfaces as music players. But, the display is relatively
high resolution (~2000x1500) yet small. So, all of the controls are
ridiculously small -- I have to use a stylus or mouse to activate them
(then why have a touch screen???)

Had the applications been developed with physical size a constraint for the
controls, the screen would be more useful/usable and the relative amounts
of real estate devoted to nonessential \"stuff\" changed accordingly.
(I\'d rather a set of buttons to operate that fit my fingertips than a
large display of the album cover!)

If I store (server side in database) characteristics of each UI device,
then I can adjust the rendered image *in* the server -- along with any
potential layout consequences -- instead of relying on the browser to
be able to \"read minds\". It also avoids issues with typefaces/glyphs/icons;
let the server decide EXACTLY what everything should look like, how
big they should be, how closely spaced, etc.

And if your screen is too tiny (phone) doing the simplest of html
\"<img>\" thing will let you just stretch the image with two fingers.

Yes, but you wouldn\'t have to keep doing that for each new page update
(or different page).

Alternatively, you can listen to how the browser announces itself
and do say 4 (or even 9) pixels for 1 etc. at your (server) side.

Exactly. But, you need a bit more information than is typically available
in the user agent\'s header.

Martin Brown said something about png instead of gif, if link
mapping works with these on old browsers this is not a bad idea.
Not because of compression, bandwidth is not such a huge issue
nowadays for that sort of app, but because of the colours. gif
allows just 256 - plenty for your purpose but if you can get
more (without compromising compatibility with older browsers)
why not.

Implementation detail. :>

if the gif is larger than the window any browser should be able to allow
you to scroll it etc (you might need that for large directories,
vertically).

Yes, exactly.  No need to have a scrollbar widget *in* the HTML.

Probably avoiding any widgets and that sort of thing like the plague
is a must, the gif approach makes sense only if you want to be
say 20+ years backward compatible. Just ancient html.

If you try to be \"current\", then you end up with all of the incompatibilities
issues to resolve. Or, have to resort to testing every potential client.
(or, restricting yourself to a particular client(s) -- ick!)

Otherwise you can even supply a link to cause the browser download from
you and run realVNC, they have a set of files for that IIRC (I did
investigate that some years ago but I abandoned it as customers
were just happy to install realVNC on its own).

That works in your case because there are binaries (of RealVNC) available
for the platforms that will host your UIs. And, the hardware is almost
certainly large enough for the user to be able to see everything on
your screens (you didn\'t design your screens with the possibility
of rendering to a phone display, did you? :> )

I originally designed these sorts of \"external\" UIs using glass TTYs
in the early 80\'s. You didn\'t have touch capability or even pointing
devices. But, tabbing to select controls was infinitely more convenient
than the sorts of HARDWARE controls (buttons and knobs) you could have on
a \"control panel\". And, with support for many more options than you could
fit in a small space, otherwise!

(plus, being able to call up instructions on a per control basis
instead of having a cheat sheet taped to the instrument or, worse,
relying on the user to remember how everything worked in every case)

I, later, did something similar with a \"Handspring\" PDA tethered to
it\'s \"host\" via a serial cable. Instead of generic keystrokes,
I could pass \"command strings\" over the interface to signal the
user\'s intentions and device\'s replies.

With a fatter pipe -- and wireless technology being ubiquitous -- I
can put less smarts in the client (because those \"smarts\" limit
what the client can do) and still have a responsive interface
that can adapt to the needs of the application(s) that it supports.

If I can leverage something that is already present in many devices
(e.g., a browser), then my job gets that much easier! :>

 

[Don Y]

On 6/12/2023 5:09 AM, legg wrote:

On Sun, 11 Jun 2023 06:32:45 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

Use the old HTML composer from netscape?

Still included in Mozilla Seamonkey.

My memory of that was that it was just an HTML editor. I.e.,
insert a tag and it would insert the closing counterpart and
let you fill in the stuff between.

I was looking for something that would wrap HTML primitives
and build more complex controls from them. To take most
of the grunt work out of the UI design.

[Ideally, with a GUI \"form editor\" but I can live without that]

 

[Liz Tuddenham]

Don Y <blockedofcourse@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

I use Claris Homepage 3.0, which is WYSIWYG but generates plain HTML.
Some of the tags are \'deprecated\', but they work on every browser I have
been able to test them with. The \'image maps\' were generated with
PageMill 3.0.

Examples:
http://www.coalcanal.org
http://www.dorandsomcanal.org
http://www.poppyrecords.co.uk
http://www.bathtram.org
http://www.tedkendall.com

Some of those pages are generated by PHP on the server from spreadsheets
of events listings etc, but they are still in plain HTML and
indistinguishable from the rest. I am even working on a
browser-independent shop sales suite of programs, but I don\'t have much
time to spare and progress is slow.

Writing browser-independent software is hard work compared with filling
in a painting-by-numbers template, but it means you know exactly what it
will do on every machine. You may not even be aware that some bought-in
website has told a valuable customer \"Your browser isn\'t good enough for
our website - you need to buy a new computer\" - yes, one did it to me
and I am now very reluctant to deal with that firm.


--
~ Liz Tuddenham ~
(Remove the \".invalid\"s and add \".co.uk\" to reply)
www.poppyrecords.co.uk

 

[Martin Brown]

On 12/06/2023 13:09, legg wrote:

On Sun, 11 Jun 2023 06:32:45 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

Use the old HTML composer from netscape?

I was a long time fan of HotMetal until it ceased to exist.
One of the first WYSIWYG HTML editors. I got a free sample.

These days I suggest BlueGriffon to newbies wanting to compose webpages
from scratch. There is a dual view mode where you can see both the HTML
source code and rendered web page display in real time.

Most go with something like WordPress though.

I remain unable to see any merit in it (WP etc) unless you enjoy
defending sites from massive script attacks on a daily basis. The
monthly nature of the image repository put me off it pretty quickly and
that was supposedly on a high end and fully capable version.

Still included in Mozilla Seamonkey.

RL

Increasingly I see opaque convoluted and grossly overweight WordPress
sites that superficially look OK provided that you don\'t look too hard

--
Martin Brown

 

[Don Y]

On 6/12/2023 5:42 AM, Don Y wrote:

I was looking for something that would wrap HTML primitives
and build more complex controls from them.  To take most
of the grunt work out of the UI design.

[Ideally, with a GUI \"form editor\" but I can live without that]

Here\'s one set of prebuilt controls:
<https://designrevision.com/demo/shards/>
there are numerous others with similar capabilities.

But, they place additional requirements on the browser
implementation and have to work around incompatibilities
between browsers (which?). AFAICT, all of the controls can be
implemented/emulated without all that.

I\'d like to just count on \"stuff\" that EVERY browser should be able to
reliably render. If I have to install something, that limits what
I can use for UI devices (and, why limit yourself to the browser route
if you\'re willing to install some code?)

 

[Don Y]

On 6/12/2023 5:42 AM, Liz Tuddenham wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

I use Claris Homepage 3.0, which is WYSIWYG but generates plain HTML.
Some of the tags are \'deprecated\', but they work on every browser I have
been able to test them with. The \'image maps\' were generated with
PageMill 3.0.

Examples:
http://www.coalcanal.org
http://www.dorandsomcanal.org
http://www.poppyrecords.co.uk
http://www.bathtram.org
http://www.tedkendall.com

Some of those pages are generated by PHP on the server from spreadsheets
of events listings etc, but they are still in plain HTML and
indistinguishable from the rest. I am even working on a
browser-independent shop sales suite of programs, but I don\'t have much
time to spare and progress is slow.

But these seem to mainly be text+image (photographs/illustrations).

Imagine a page that *controls* something. Like your oven. Or, your TV.
Sure, you can have a \"+\" icon to increase the volume (click it until
you are happy with the setting). But, that\'s letting the implementation
define the interface instead of letting the user define it (and the
implementation mimicking his needs) Perhaps a slider is a more intuitive
control (for that function)?

Writing browser-independent software is hard work compared with filling
in a painting-by-numbers template, but it means you know exactly what it
will do on every machine.

Exactly. And, if you ask the least from the browser, then you likely
risk less disappointment.

What I would like is the least from teh browser (most portable)
yet ease of design (control abstractions that a toolkit renders
to HTML accordingly). Like using arithmetic operators to indicate
the instructions I want a processor to execute and the applicable
operands (YOU deal with the boring details, not me!)

You may not even be aware that some bought-in
website has told a valuable customer \"Your browser isn\'t good enough for
our website - you need to buy a new computer\" - yes, one did it to me
and I am now very reluctant to deal with that firm.

Imagine someone using a (\"incompatible\") browser and later complaining to
you that YOUR product is broken. How happy do you think they will be
when you politely inform them that they were using an unapproved browser?
Now, they have to update their browser just to make use of YOUR product!

(why do they have to bear the cost for your poor design decision?)

 

[Don Y]

On 6/12/2023 5:55 AM, Martin Brown wrote:

Increasingly I see opaque convoluted and grossly overweight WordPress sites
that superficially look OK provided that you don\'t look too hard

This is characteristic of most software. Folks use building blocks
without understanding their limitations or applicability (why do
you need to run Linux in EVERYTHING? Does it make sense for a
TV to have a filesystem? Yeah, I know you can find a use for it
but would you write one from SCRATCH as a *requirement* for the
device? Are you sure you know all of the bugs in the inherited
implementation?? Are you prepared to maintain all of that code?
Or, will it quickly become an \"unsupported\" product?)

The few WP sites that I\'ve seen seem to spend a lot of time
trying to look flashy. But, the content isn\'t! Gold plated
hubcaps on a VW...

 

[Dimiter_Popoff]

On 6/12/2023 15:15, Don Y wrote:

On 6/12/2023 4:22 AM, Dimiter_Popoff wrote:
On 6/12/2023 3:30, Don Y wrote:
On 6/11/2023 1:48 PM, Dimiter_Popoff wrote:
....
What I suggest is indeed the most rudimentary way of doing it; you will
do a tiny html envelope for the gif you generate (no sizes etc. need to
be mentioned, this will potentially cause browser independence loss);

Why wouldn\'t I want to declare a size (pixels)?  I would know it as I
would
generate the GIF and the HTML...

Some (most? all?) browsers will start to scale your image to the
specified size and thus blur it etc. If you don\'t specify any size
the browsers will go 1:1 pixels, there may be hard to find exceptions
but I don\'t know of any.

But I would deliberately draw (render) the image AT the size (resolution)
of the client\'s display.  The whole point of this is to take effort
(and responsibility) out of the client\'s hands.

E.g., I use some MSSurfaces as music players.  But, the display is
relatively
high resolution (~2000x1500) yet small.  So, all of the controls are
ridiculously small -- I have to use a stylus or mouse to activate them
(then why have a touch screen???)

Had the applications been developed with physical size a constraint for the
controls, the screen would be more useful/usable and the relative amounts
of real estate devoted to nonessential \"stuff\" changed accordingly.
(I\'d rather a set of buttons to operate that fit my fingertips than a
large display of the album cover!)

If I store (server side in database) characteristics of each UI device,
then I can adjust the rendered image *in* the server -- along with any
potential layout consequences -- instead of relying on the browser to
be able to \"read minds\".  It also avoids issues with
typefaces/glyphs/icons;
let the server decide EXACTLY what everything should look like, how
big they should be, how closely spaced, etc.

For scaling *up* this makes sense, I was thinking more about the
scale down case.

....

That works in your case because there are binaries (of RealVNC) available
for the platforms that will host your UIs.  And, the hardware is almost
certainly large enough for the user to be able to see everything on
your screens (you didn\'t design your screens with the possibility
of rendering to a phone display, did you?  :> )

Actually it works over a phone well enough, realVNC for android scales
up automatically and you can pinch it any way you like etc. There is
also at least one android app which is rfb compatible and works with
netMCA-s. Neither is as convenient as is realVNC for desktop of course
but they are usable allright. Both with my current phone (with some
ridiculously high pixel count/small pixel count display) and with my
first one, 10+ years ago, it had less pixels than the display...

http://tgi-sci.com/tgi/mob1.gif (the oldest phone, 10+ years ago)

 

[Don Y]

On 6/12/2023 6:35 AM, Dimiter_Popoff wrote:

If I store (server side in database) characteristics of each UI device,
then I can adjust the rendered image *in* the server -- along with any
potential layout consequences -- instead of relying on the browser to
be able to \"read minds\".  It also avoids issues with typefaces/glyphs/icons;
let the server decide EXACTLY what everything should look like, how
big they should be, how closely spaced, etc.

For scaling *up* this makes sense, I was thinking more about the
scale down case.

Put less on the screen. Or, refuse to work on \"too small\" devices.
Imagine running netmca on an apple watch. Even if you *could*
make out all of the detail (zoom/pan/scan), it\'s just not the right
sort of i/f for the instrument.

That works in your case because there are binaries (of RealVNC) available
for the platforms that will host your UIs.  And, the hardware is almost
certainly large enough for the user to be able to see everything on
your screens (you didn\'t design your screens with the possibility
of rendering to a phone display, did you?  :> )

Actually it works over a phone well enough, realVNC for android scales
up automatically and you can pinch it any way you like etc. There is

But the amount of content on your screens (e.g., the file explorer)
seems like it would strain a user to try to sort out the detail, there.
You\'d be spending all your time working around the constraints of the
display device instead of concentrating on what you were trying to do.

It\'s like trying to read a PDF on an eReader. The format doesn\'t
reflow to fit the size/shape of the screen. So, you\'re always
pan/scan around the page trying to read the next paragraph or
next column.

[I\'ve been looking for a nice 14\" tablet for just this reason...
display documents full/A size!]

also at least one android app which is rfb compatible and works with
netMCA-s. Neither is as convenient as is realVNC for desktop of course
but they are usable allright. Both with my current phone (with some
ridiculously high pixel count/small pixel count display) and with my
first one, 10+ years ago, it had less pixels than the display...

http://tgi-sci.com/tgi/mob1.gif  (the oldest phone, 10+ years ago)

How do you click the little buttons in the lower center?
Or, adjust the sliders? Your fingers end up in the way of what
you\'re seeing...

[And you positioned the 8P8C with the locking tab down. I\'ve been
canvasing folks over whether down or up is most \"friendly\". Or,
was that just a consequence of how it was mounted on the PCB?]

 

[Dimiter_Popoff]

On 6/12/2023 16:52, Don Y wrote:

On 6/12/2023 6:35 AM, Dimiter_Popoff wrote:
....
That works in your case because there are binaries (of RealVNC)
available
for the platforms that will host your UIs.  And, the hardware is almost
certainly large enough for the user to be able to see everything on
your screens (you didn\'t design your screens with the possibility
of rendering to a phone display, did you?  :> )

Actually it works over a phone well enough, realVNC for android scales
up automatically and you can pinch it any way you like etc. There is

But the amount of content on your screens (e.g., the file explorer)
seems like it would strain a user to try to sort out the detail, there.
You\'d be spending all your time working around the constraints of the
display device instead of concentrating on what you were trying to do.

It is less convenient to use via a touchscreen than from a \"normal\"
laptop but this is valid for almost anything having to do with real
work. The ability to access it from my phone has been quite valuable
for me as customers, demos etc. (\"why can my laptop not see it?\"
\"there, my phone sees it over your network, you have messed with
your laptop, let me check\").

It\'s like trying to read a PDF on an eReader.  The format doesn\'t
reflow to fit the size/shape of the screen.  So, you\'re always
pan/scan around the page trying to read the next paragraph or
next column.

[I\'ve been looking for a nice 14\" tablet for just this reason...
display documents full/A size!]

also at least one android app which is rfb compatible and works with
netMCA-s. Neither is as convenient as is realVNC for desktop of course
but they are usable allright. Both with my current phone (with some
ridiculously high pixel count/small pixel count display) and with my
first one, 10+ years ago, it had less pixels than the display...

http://tgi-sci.com/tgi/mob1.gif  (the oldest phone, 10+ years ago)

How do you click the little buttons in the lower center?
Or, adjust the sliders?  Your fingers end up in the way of what
you\'re seeing...

Both realVNC and the other (pocketcloud, no longer on googleplay
or whatever, something other under that name is there but works
on android 12 after going through the installation warnings) are
designed to mimick a mouse and keyboard interface. You can see the
phone \"mouse\" as a dot, underneath the netMCA mouse cursor is following
it so you can drag the mouse to what you want to click then
tap anywhere. The mouse cursor is smart enough to not hide under
your finger. Obviously it is not as convenient as it is with
a normal PC but it is usable, I have used it plenty of times after
having gone to bed to see how something I have left some unit do
is going etc.

[And you positioned the 8P8C with the locking tab down.  I\'ve been
canvasing folks over whether down or up is most \"friendly\".  Or,
was that just a consequence of how it was mounted on the PCB?]

Oh this was just how the RJ-45 I could buy back then was made,
I never gave that a thought. I must have had a lot less choices
back then to get an RJ-45 for 10/100 with magnetics than there
are today, I have not even considered that. For all the switches
and rooters mess here I just sense with my finger which way
around is it, every time. I don\'t have any preference, only some
cables with broken locks which go out when I mess with some others
and I swear for a few minutes until I put it all back together.

 

[Liz Tuddenham]

Don Y <blockedofcourse@foo.invalid> wrote:

On 6/12/2023 5:42 AM, Liz Tuddenham wrote:
Don Y <blockedofcourse@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

I use Claris Homepage 3.0, which is WYSIWYG but generates plain HTML.
Some of the tags are \'deprecated\', but they work on every browser I have
been able to test them with. The \'image maps\' were generated with
PageMill 3.0.

Examples:
http://www.coalcanal.org
http://www.dorandsomcanal.org
http://www.poppyrecords.co.uk
http://www.bathtram.org
http://www.tedkendall.com

Some of those pages are generated by PHP on the server from spreadsheets
of events listings etc, but they are still in plain HTML and
indistinguishable from the rest. I am even working on a
browser-independent shop sales suite of programs, but I don\'t have much
time to spare and progress is slow.

But these seem to mainly be text+image (photographs/illustrations).

Imagine a page that *controls* something. Like your oven.

Something like this?

http://www.poppyrecords.co.uk/other/Boiler/B2c.php

Imagine someone using a (\"incompatible\") browser and later complaining to
you that YOUR product is broken. How happy do you think they will be
when you politely inform them that they were using an unapproved browser?
Now, they have to update their browser just to make use of YOUR product!

(why do they have to bear the cost for your poor design decision?)

That is why I write my websites in HTML with no CSS, no javascript nor
any other code that\'s too clever for its own good. As soon as you
expect the user\'s computer to do something clever, you will finish up
excluding potential clients. I test the webpages myself with
20-year-old browsers and then get friends to test them with tablets and
mobile \'phones. No failures yet.


--
~ Liz Tuddenham ~
(Remove the \".invalid\"s and add \".co.uk\" to reply)
www.poppyrecords.co.uk

 

[Don Y]

On 6/12/2023 7:23 AM, Dimiter_Popoff wrote:

But the amount of content on your screens (e.g., the file explorer)
seems like it would strain a user to try to sort out the detail, there.
You\'d be spending all your time working around the constraints of the
display device instead of concentrating on what you were trying to do.

It is less convenient to use via a touchscreen than from a \"normal\"
laptop but this is valid for almost anything having to do with real

But that\'s because most interfaces that people design are too cluttered.
Too much information and too many controls (when the controls are \"soft\".

If, instead, you can spread the information and controls over multiple
(logical) screens, then you don\'t need to rely on as fine of pointing
skills. Or, hide the controls *behind* the associated displays
(e.g., touching a graph brings up the controls for that graph IN PLACE
OF the graph).

E.g., I have 240 nodes, here. Any one (or many!) can alarm (for a variety
of reasons). How do you graphically indicate where it/they is/are?
I present a floorplan of the house/lot with indicators to highlight
the alarming nodes. Touch a room and the display of the room replaces
the display of the house -- because that\'s a logical way of folks
to think of the interface behaving. If multiple indications in a
given room, touch the point on the display that you want to be
panned to the center of the display and zoomed.

This lets the user be imprecise in how he interacts with the
display/control and doesn\'t result in any \"surprises\".

work. The ability to access it from my phone has been quite valuable
for me as customers, demos etc. (\"why can my laptop not see it?\"
\"there, my phone sees it over your network, you have messed with
your laptop, let me check\").

No doubt! In my case, there\'s no \"place\" where a user interacts with the
kit. So, the interface has to be portable; it has to be small and
light so he doesn\'t feel burdened carrying (or wearing) it around.

It\'s like trying to read a PDF on an eReader.  The format doesn\'t
reflow to fit the size/shape of the screen.  So, you\'re always
pan/scan around the page trying to read the next paragraph or
next column.

[I\'ve been looking for a nice 14\" tablet for just this reason...
display documents full/A size!]

also at least one android app which is rfb compatible and works with
netMCA-s. Neither is as convenient as is realVNC for desktop of course
but they are usable allright. Both with my current phone (with some
ridiculously high pixel count/small pixel count display) and with my
first one, 10+ years ago, it had less pixels than the display...

http://tgi-sci.com/tgi/mob1.gif  (the oldest phone, 10+ years ago)

How do you click the little buttons in the lower center?
Or, adjust the sliders?  Your fingers end up in the way of what
you\'re seeing...

Both realVNC and the other (pocketcloud, no longer on googleplay
or whatever, something other under that name is there but works
on android 12 after going through the installation warnings) are
designed to mimick a mouse and keyboard interface. You can see the
phone \"mouse\" as a dot, underneath the netMCA mouse cursor is following
it so you can drag the mouse to what you want to click then
tap anywhere.

Ah! That would be hard for (my) users to use; it would require
more patience and fine vision/motor skills. Imagine moving a mouse
cursor to one of the alarm sites in the house example, above.

The mouse cursor is smart enough to not hide under
your finger. Obviously it is not as convenient as it is with
a normal PC but it is usable, I have used it plenty of times after
having gone to bed to see how something I have left some unit do
is going etc.

But we\'re not \"normal\" users. We have higher motivations and
stakes.

[And you positioned the 8P8C with the locking tab down.  I\'ve been
canvasing folks over whether down or up is most \"friendly\".  Or,
was that just a consequence of how it was mounted on the PCB?]

Oh this was just how the RJ-45 I could buy back then was made,
I never gave that a thought. I must have had a lot less choices
back then to get an RJ-45 for 10/100 with magnetics than there
are today, I have not even considered that. For all the switches
and rooters mess here I just sense with my finger which way
around is it, every time. I don\'t have any preference, only some
cables with broken locks which go out when I mess with some others
and I swear for a few minutes until I put it all back together.

I\'ve tried watching how I approach \"unconstrained\" connectors
of that sort (in some cases, there is no choice. E.g., the
connectors on most switches are in two rows so the top row\'s
tabs are above while the bottom row\'s are below). Am I using
the tip of my thumb to engage the tab? Or the side of another
finger?

It is particularly distressing when you can\'t see the connector
and have to resort to feel -- esp if there is no real clearance
on either side (due to the placement of other connectors or
case parts).

 

[Don Y]

On 6/12/2023 7:54 AM, Liz Tuddenham wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

On 6/12/2023 5:42 AM, Liz Tuddenham wrote:
Don Y <blockedofcourse@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

I use Claris Homepage 3.0, which is WYSIWYG but generates plain HTML.
Some of the tags are \'deprecated\', but they work on every browser I have
been able to test them with. The \'image maps\' were generated with
PageMill 3.0.

Examples:
http://www.coalcanal.org
http://www.dorandsomcanal.org
http://www.poppyrecords.co.uk
http://www.bathtram.org

The tram (?) looks like a UFO -- with wheels! :>

http://www.tedkendall.com

Some of those pages are generated by PHP on the server from spreadsheets
of events listings etc, but they are still in plain HTML and
indistinguishable from the rest. I am even working on a
browser-independent shop sales suite of programs, but I don\'t have much
time to spare and progress is slow.

But these seem to mainly be text+image (photographs/illustrations).

Imagine a page that *controls* something. Like your oven.

Something like this?

http://www.poppyrecords.co.uk/other/Boiler/B2c.php

It would likely have a smaller range, centered around the current
temperature (setting), that would shift up or down as the user
picked points at either extreme. A point within the displayed range
would set to the corresponding temperature.

I don\'t rely on people having good fine motor skills as many
\"normal\" people suffer from essential tremor which hinders
their ability to finely position their extremities. \"Picking\" a
setting that wasn\'t what they intended (but was where their
finger landed!) would frustrate them.

Also, the colors would be ... \"wrong\" after Daltonizing. So,
best just to show none or a simple gradation in value (not hue).

Imagine someone using a (\"incompatible\") browser and later complaining to
you that YOUR product is broken. How happy do you think they will be
when you politely inform them that they were using an unapproved browser?
Now, they have to update their browser just to make use of YOUR product!

(why do they have to bear the cost for your poor design decision?)

That is why I write my websites in HTML with no CSS, no javascript nor
any other code that\'s too clever for its own good. As soon as you
expect the user\'s computer to do something clever, you will finish up
excluding potential clients.

It doesn\'t even have to be particularly clever. Bugs exist because of
mistakes as well as misunderstandings.

E.g., in the days of glass TTYs, different manufacturers would exhibit
different \"quirks\" in their ANSI 3.64 implementations. If your code
tickled one of them, you likely wouldn\'t know it (because you probably
only had TTYs from one or two makes/models).

Does the guy who bought a \"quirky\" TTY deserve to be penalized for
his purchase decision? He likely was unaware of the quirk and no other
software may ever have tickled it, before! Worse yet, would he realize the
problem lay in the TTY and NOT your code?? Would he believe you if you
explained that to him? Would he CARE??

I test the webpages myself with
20-year-old browsers and then get friends to test them with tablets and
mobile \'phones. No failures yet.

Imagine having to test against each *version* of each browser (cuz you
don\'t know that the customer/user has the latest version of a browser).

And, devices that have embedded browsers that can no longer be upgraded
(one of my TVs suffers from this \"condition\"). Imagine buying a refrigerator
with a browser-in-the-door and discovering that it doesn\'t render your
page correctly (unlikely that you have said refrigerator on hand in all
of its revisions!).

 

[Liz Tuddenham]

Don Y <blockedofcourse@foo.invalid> wrote:

[...]

Imagine a page that *controls* something. Like your oven.

Something like this?

http://www.poppyrecords.co.uk/other/Boiler/B2c.php

It would likely have a smaller range, centered around the current
temperature (setting), that would shift up or down as the user
picked points at either extreme. A point within the displayed range
would set to the corresponding temperature.

I don\'t rely on people having good fine motor skills as many
\"normal\" people suffer from essential tremor which hinders
their ability to finely position their extremities. \"Picking\" a
setting that wasn\'t what they intended (but was where their
finger landed!) would frustrate them.

Also, the colors would be ... \"wrong\" after Daltonizing. So,
best just to show none or a simple gradation in value (not hue).

That was just a demo page that I did for a friend to show that this sort
of control interface was possible with browser-independent HTML
supported by PHP running in the background on the server. You can
change the colours, scaling etc. to suit your particular application.

[...]

Does the guy who bought a \"quirky\" TTY deserve to be penalized for
his purchase decision?
He likely was unaware of the quirk and no other
software may ever have tickled it, before! Worse yet, would he realize the
problem lay in the TTY and NOT your code?? Would he believe you if you
explained that to him? Would he CARE??

That\'s why there are standards, to prevent that sort of thing happening.
If a rogue manufacturer doesn\'t follow the standard, the product ought
to get a bad name very quickly.

[...]
> And, devices that have embedded browsers that can no longer be upgraded

If a browser can\'t cope with HTML, it isn\'t much use. Browsers become
\'outdated\' because websites keep trying to be clever and won\'t follow
the basic standards. The more you pay for a website, the less likely
it is to work properly. The web designer\'s customer doesn\'t know he is
being conned because the users who can\'t see the website can\'t leave any
feedback.

\"No wheelchair users have ever come in and complained about the steps
outside.\"

--
~ Liz Tuddenham ~
(Remove the \".invalid\"s and add \".co.uk\" to reply)
www.poppyrecords.co.uk

 

[Don Y]

On 6/12/2023 2:13 PM, Liz Tuddenham wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

[...]
Imagine a page that *controls* something. Like your oven.

Something like this?

http://www.poppyrecords.co.uk/other/Boiler/B2c.php

It would likely have a smaller range, centered around the current
temperature (setting), that would shift up or down as the user
picked points at either extreme. A point within the displayed range
would set to the corresponding temperature.

I don\'t rely on people having good fine motor skills as many
\"normal\" people suffer from essential tremor which hinders
their ability to finely position their extremities. \"Picking\" a
setting that wasn\'t what they intended (but was where their
finger landed!) would frustrate them.

Also, the colors would be ... \"wrong\" after Daltonizing. So,
best just to show none or a simple gradation in value (not hue).

That was just a demo page that I did for a friend to show that this sort
of control interface was possible with browser-independent HTML
supported by PHP running in the background on the server. You can
change the colours, scaling etc. to suit your particular application.

Yes, of course. My point is that you can\'t just have a \"pick
A temperature in this range\" approach to the control. Just like
you can\'t point to a spot in a whole-house floorplan (see my
comment to Dimiter).

If designing a \"tangible\" instrument, you WOULD have a
\"temperature setting\" knob that directly controlled the
temperature without this incremental sort of approach.

Does the guy who bought a \"quirky\" TTY deserve to be penalized for
his purchase decision?
He likely was unaware of the quirk and no other
software may ever have tickled it, before! Worse yet, would he realize the
problem lay in the TTY and NOT your code?? Would he believe you if you
explained that to him? Would he CARE??

That\'s why there are standards, to prevent that sort of thing happening.
If a rogue manufacturer doesn\'t follow the standard, the product ought
to get a bad name very quickly.

Standards are only as good as their enforcement/adherence. Without a
\"certifying authority\", how do you know -- for sure -- that an
implementation is 100% conformant (in all cases)?

I recall one terminal that stored control sequences IN the \"frame buffer\",
consuming positions that should have been used for characters! (WTF?)

Others used in-band signaling for control codes so certain combinations
of characters couldn\'t be displayed. Sort of like avoiding ??! in C
statements!

\"Standards are great; everyone should have one!\"

And, devices that have embedded browsers that can no longer be upgraded

If a browser can\'t cope with HTML, it isn\'t much use.

But browsers (as anything) are designed based on what is \"current\"
when the code is released. There\'s no requirement for a manufacturer
to update the browser embedded in his device to remain current;
the product simply is reclassified as \"unsupported\"!

Browsers become
\'outdated\' because websites keep trying to be clever and won\'t follow
the basic standards. The more you pay for a website, the less likely
it is to work properly. The web designer\'s customer doesn\'t know he is
being conned because the users who can\'t see the website can\'t leave any
feedback.

\"No wheelchair users have ever come in and complained about the steps
outside.\"

I frequently encounter pages that \"don\'t work\". Is it because I\'ve disabled
scripts from some domain that are essential to that page? If I remove these
restrictions, why doesn\'t the page appear correctly? Do I have to run
TWO browsers just to see if the page is at fault vs. a browser??

Like having two radios: one with the AM section broken and the other with
the FM section broken...?