Website Update Update

I continued to tweak the meta tag settings on some of the pages to get them to look right on mobile devices. I got to test things on several different phones yesterday, which helped a lot. What I came up with was this:

This setting worked well to scale most of the pages in an effective way. It fits the header in without extra line breaks and ensures the content fills up most of the width of the page. This is the desired result for most pages, in both portrait and landscape modes. This is most important on the Roles and Portfolio main pages, where I wanted the header to be spaced without line breaks while the content displays as a single column of article entries that fill the width of the screen.

The home page needs to accommodate a slightly wider header and two fairly wide elements at the top of the page while ensuring that the article entries (duplicates of those found on the Roles page) show up in a single column filling the width of the screen. I tried setting the width directly to 750 in an attempt to get the page behavior I wanted but that made the display run off the right side of the screen. Then I tried setting the scale down to 0.5 and got the effect I wanted. I can’t say I understand this quite yet, I need to read more, but it worked well on a number of devices. Interestingly, when some phones are rotated to landscape mode the header and top elements still look OK while the articles show up three across at their 350-pixels wide setting. That actually works for me.

Finally, I wanted the resume page to be displayed in a zoomed-out format that would make the layout most closely match the way it would look on the printed page. The solution that worked best was commenting the meta tag out altogether. This just lets each device take its best shot at rendering something at its native resolution. I don’t know how this will look on significantly older phones but it looked about the way I wanted it on all of those I tried. I see that my phone scales down the text in the two sections arranged as three columns of bullets while the remainder of the non-header text is of uniform size.

Last but not least I saw that the site would route the user to the address rpchurchill.com/rpc/, which generated a server error. If the rpc/ was hand-edited off the address then everything worked, but that was clearly not acceptable. This seemed to be a reference to the site’s root directory on my webhost’s server. The root directories of all my domains on that service share the same master parent directory. A brief inspection showed a stray .htaccess file in that shared master directory left over from moving the WordPress installation down one level. I changed the name of that file, effectively deleting it, and that solved the problem.

I’m not saying this setup is optimal but it seems to work and doesn’t involve code. I learned a lot by going through this process and it gives me a good basis for learning and asking questions going forward.

In the meantime feel free to let me know if anything doesn’t look right on one of your devices. This is especially true if you have suggestions for better ways to do any of it. đŸ™‚

Posted in Software | Tagged , | Leave a comment

Website Update Mostly Complete

I slogged through and got the hard part done. Migrating the WordPress installation down one directory was blissfully easy and the rest of it was just applying elbow grease and being thorough. It’s nice having a true landing page. That said, the materials need some tweaking there and I have to make backing pages for some of the articles on the Roles page. I may add a couple more articles on the Portfolio page.

Everything looks OK on a regular computer but it’s not behaving the way I’d like on my phone. The Roles and Portfolio pages were showing up on my phone with the articles in two columns. Its actual pixel width is 750 so I set the responsive breakpoint to 860 pixels. It stretches the articles out so they’re up to 650 pixels across below a screen width of 860, which means they show up as only one column. Above a screen width of 860 the articles assume a standard maximum width of 350, which means they’ll display as many across as the screen width will fit (effectively up to four because I cap the page width at 1600). The idea was that 750 was less than 860 so the articles would be 650 and only show up as one column sized reasonably to most phones.

Problem: the effective pixel width of my iPhone 7 is 980 pixels. That’s larger than my breakpoint and yielded two columns of 350-pixel articles.

I quickly looked around for some kind of solution and tried the following (this appears to have no effect on desktop browsers):

In theory this should set the effective screen size to 600, which would be perfect for my needs. It would look good on most devices. This setting doesn’t appear to do what I thought it did, however. It looks like it fits about 2/3s of the image on the screen. Is this 600 / 980 -ish? I can pinch it into place but I have to do that for every new page, even after rebooting the phone, so that’s highly non-optimal.

This is annoying but it’ll have to keep for a bit. I’ll definitely be doing some more reading and experimenting until this makes sense to me. It may well take some coding. We shall see.

Posted in Software | Tagged , , | Leave a comment

Website Update In Progress

I’m in the process of hand-editing all of the static webpages and I think it’s coming together reasonably. Doing these pages over and over again makes it clear that I should be doing at least the simplest level of automation, which is using common header and footer sections and tying the pieces together using simple PHP.

While that or something like it should be straightforward I still have to migrate the WordPress installation down one level and make sure the responsive ideas I’ve had actually work on mobile devices. I think what I’ve done will work, but I won’t know what I’ve done will work until I see it. Murphy’s Law and all that…

Posted in Software | Tagged , , | Leave a comment

Responsive Design: One Observation

I try to keep digging until I understand things from first principles if it’s at all practical. I won’t claim I’m above settling for a temporary fix if there’s a deadline or so I can move on for a while, but I don’t like doing it and will try to circle back to get it right when I can. I’ll definitely comment or otherwise document the loose end.

Today’s invocation of this desire involved making the new static pages reasonably responsive. It took several cycles of reading and experimenting with things until the pieces started to come together in my mind. I’ll spare you the details and a long list of links; you’re welcome to check the CSS when it’s all done. Until then the observation is that I saw that the idea of trying to target configurations for individual devices is a mug’s game. To put this even more strongly I was thinking you’d have to be on crack to try to jump through all those hoops. I knew there had to be a simpler way but I didn’t yet know what it was.

This impression was confirmed during my continued reading but I still had to figure out why different files were acting inconsistently on different devices (I was using my phone, a couple different browsers on my PC, and the test capability in Chrome that I’d discovered previously). “Why,” I asked myself, “is a media query applying when the screen size clearly indicates that it shouldn’t?” That’s when I finally “got” what the meta/viewport element is for and that I need to include it in all the HTML files.

This (also pay special attention to the notes at the very bottom of this page) tells the device to treat its operational resolution as its native, physical resolution.

I get why devices try to scale things and I’ve noticed this on my iPhones over time, especially my own WordPress pages. It seems much simpler to not have to predict what different devices are going to do. Monkeying with this stuff takes enough effort without having to deal with extra steps.

There are doubtless a few inconsistencies left to stumble over but I’m thinking the rest of this process just got a lot easier.

Posted in Software | Tagged , , | Leave a comment

Random Explorations

Over the past few weeks I met two nice people who have both built websites based on Jekyll (the newer one was actually based on OctoPress). As I’m redoing my website I’m trying to find a good way to make the blog content be somewhat deemphasized in favor of the more or less static content. The simplest way to do this would be to migrate the WordPress installation down one directory level and install the static content in the root (and its subdirectories). As it is now the static content that really should constitute the landing page is stored a couple of levels down. It and the resume page are linked semi-conspicuously at the top of the WordPress page so it’ll keep for now.

I will, however, pirate some of the layout ideas from the OctoPress framework, though I have no plans to use that framework. The front content is meant to be static, after all, and the blog content is the blog content. They are different. In the meantime the article layout of the “front” pages ends up being flexible and responsive without incorporating Bootstrap or something similar. The new stuff will make an appearance over the next couple of days and I’ll work out a more permanent solution after that.

Posted in Software | Tagged , , | Leave a comment

WebGL: Incorporating Device Orientation

At last night’s DCJS Meetup (specifically Sean’s talk referencing this) I learned that a means of reading the 3D orientation of a device has been readily available for some time. Descriptions were not hard to find.

Setting up the listener is easy enough. The window.DeviceOrientationEvent test will actually pass on a lot of devices, including my laptop, even if they don’t actually fire off the update events, therefore I initialize the angles to null and use them as a test for updating the camera orientation.

If the orientation events don’t fire then I let the camera move and continue to look at the origin of the scene as before but if the events to fire I stop the camera from moving and update its orientation in space instead. The 90 degree adjustment for rotation around the X-axis was something I added to make the view make sense. That may be an artifact of the coordinate system I set up. An additional adjustment may be necessary on Firefox on some devices.

Here’s a direct link to test on your mobile device. Let me know if it works for you. Here‘s a different way to see if your device even supports this functionality.

This setup looks like it works on my iPhone for small rotations but it really doesn’t behave the way I’d want it to. There’s clearly a lot more going on. I’m going to dig into that a bit later but in the meantime I found an even more direct — and easier — way to accomplish this. Addendum, February 22, 2017: No, that’s not what was going on, this is what was going on. The rotations I did accounted for the directional vector but not the rotation around that vector. This is the extra factor addressed in DeviceOrientationControls.js.

Three.js already includes a way to incorporate a device’s orientation, and that is by including the capabilities in DeviceOrientationControls.js. An example is here. I pulled all of the previous code out and replaced it with all of three new lines identified below, and also set the orbit increment to zero.

It could not be easier.

My quick hack for checking this out on your device directly is here. It won’t do anything on a device that doesn’t support sensing of orientation but it looks and works great on my phone.

The next thing I’d have to do is figure out how to determine whether the device supports this new addition and revert to the previous orbit-and-look-at-the-origin behavior.

Posted in Software | Tagged , , , | Leave a comment

WebGL Is Supported By Most Browsers — Most of the Time

Working through yesterday’s post I found it necessary to test the code in multiple browsers and, when it failed, to use the debuggers to figure out where. The different examples I’ve put together for this site and for last week’s presentation all run and ran fine on Firefox, which is where I do most of my work. Everything worked in IE and Edge as well. Nothing worked in Chrome or Opera, even though everything worked in both last week.

That’s right — now you see it, now you don’t.

Exactly why things do or do not work is dependent on two major things: details of the latest browser version (particularly in how it leverages any GPU in the system for hardware acceleration) and the version of the WebGL and Three.js libraries themselves. As of today the failures always occur when trying to create the renderer object.

Within the Three.js code the code for creating the renderer object is here, and the variable _gl ends up with a value of null and throws an exception.

This happens regardless of which (current) version of Three.js I use, with some possibilities shown below:

What’s really mystifying is that this worked in Chrome sometimes and not other times. It never works in Opera, but did last week when I was giving the presentation.

There are a couple of ways to test to see whether your browser supports WebGL. On is to go to this site:

https://get.webgl.org

It tries to initialize a simple animation of a rotating cube. If you don’t see the cube then WebGL isn’t working on your browser on your system. The page gives you a link you can use to get more information about your browser but it only leads to a dead end when you do this in Opera.

There’s also a page that tells you how to include an upfront test in your own code that allows you to provide a message that WebGL has failed. I actually used the Detector.js version I found here, but any of the tests should work.

If you run into problems one of the other important things you can do is check the status of your display drivers. When I examined my graphics drivers on Windows 10 64-bit I found an error and went ahead an deleted and re-installed the driver. Surprise of surprises, WebGL and Three.js now work in all browsers on Windows. I know it has also worked reliably on iOS.

Interestingly, however, and I remember this from testing on my 3rd gen iPad a while back, the default background color is actually white in 3D scenes, unless you explicitly set it to something else, like in this example:

Obviously this has to happen after the 3D renderer is successfully initialized.

Here’s the test code I’ve been using, which is a slight rearrangement of one of the examples I included in my presentation:

A direct link to this is here. Don’t forget to grab a copy of Detector.js if you want to test this on your own system.

Bottom line: don’t be afraid to dig into any of this stuff. This technology is proven and should be fairly stable. If it doesn’t work it’s very likely that something in your system is out of whack.

Posted in Software | Tagged , | Leave a comment

A Simple Discrete-Event Simulation: Part 82

Today I added the ability to use the mouse to drag the 2D display around within its canvas. I had to update the various pan functions to allow specification of an arbitrary distance increment, though there are a number of ways I could have done that. I may change things up going forward. In the meantime, the code sets up events for mousedown, mousemove, and mouseup events and, when the dragFlag is set to true, goes ahead and moves the 2D display by the requested increments in both the x and y directions.

I was a little bit stunned when it worked perfectly the first time I tried it, and it also works smoothly when the simulation is running full blast. Fun!

Here’s the new code for handling the mouse events:

And here’s the updated code for the pan functions. I left the limits unchanged for now.

I found it necessary to handle the mouseleave event because it was possible to mouse out of the canvas, release the mouse, return to the canvas, and still be dragging the 2D display. In order to get out of that the user would have to do a new mousedown and mouseup to properly clear the state. Perhaps it would be better to only snap back to the drag origin when the user releases the mouse when outside the canvas, when a drag sequence is in progress.

The drag mouse event code to eat that event, or prevent it from bubbling up through further elements, does run when expected, but I can’t be sure it’s doing anything. It runs when using the keystrokes as well, but the entire window will still scroll up or down when the 2D display reaches its upper or lower limits. It’s bad enough when running this page standalone but when its embedded on a WordPress page with ten other posts it wants to scroll the whole window down rather than ever scrolling the 2D display back up. This means either that the event that scrolls the larger window up and down is being processed at a lower level that the canvas and is being allowed to bubble up to the canvas, or that it isn’t actually being stopped from propagating.

I need to get a much, much better feel for how the whole event mechanism works in JavaScript, HTML, and the DOM. It’s amazing how far you can get without going into depth in some really important areas. The explanations I’ve read seem simple enough, and of course I’ve been using event-driven frameworks forever, but my work didn’t usually require me to dig into the details. I suspect this is going to keep me hopping.

In the longer run there’s a lot more to add here. For example, the canvas should only allow the user to drag when the entire image is not in view, and even then perhaps in certain modes, which themselves must be controllable. Anyway, one piece at a time, especially when I’m busy with other things.

Last but not least I ended up learning a lot more about how WebGL runs — or fails to run — on different browsers at different times. I’ll relate that saga tomorrow.

Posted in Software | Tagged , , , , | Leave a comment

A Simple Discrete-Event Simulation: Part 81

This week and possibly much of next I’m concentrating on updating the fixed content of my website, which means I’m only going to be doing small increments on this project. I’ve decided that the next item to work on is panning a zooming because of something I want to demonstrate in the fixed content. To that end I installed the simplest possible commands to pan the 2D display around within certain limits. Mostly I wanted to verify that I’d added the base x- and y-origins for the viewable area of the screen were added to all of the drawing commands properly.

Here’s the relevant code from the DisplayElement object. It shows how the drawing locations now include the offsets I’ve defined (globalBaseX and globalBaseY):

Here’s the code that does the basic pan. It picks up keystrokes and changes the base x- and y-axis panning origins within limits. When the code is running in its own window there are times when higher priority events consume the messages for the up and down arrow keys, namely when the entire page wants to scroll. When I embed this in an iframe on the website it doesn’t seem to have this problem. However, when it’s in the iframe (like you see it here) you need to click on the canvas to give it the focus. The arrow keys move the display and the home key restore the origin point to its original value. There’s no provision for panning on a mobile device, either, but at least I know the offsets are in correctly.

You may also notice that these calls update the graphics when the simulation is not running, but don’t need to do so when the simulation is running, though the panning action will be much more slow and choppy.

Posted in Simulation | Tagged , | Leave a comment

Converting the Entire Site from HTTP to HTTPS

…was painful.

Instructions for making the change effective throughout WordPress were easy enough to find and follow, but updating references in 250-ish posts by hand took some time. I had two hassles. The first was my own doing in that I put all of the local images in a named directory rather than using the WordPress way of referring to local content. This means I know where everything is and can move the WordPress installation anywhere I want without having to worry about the directory tree that it would build. The downside is that I have to include a fully qualified path to each piece of content. Oh well. The other hassle is the general issue that linking to unsecure content on a secure page makes the browser report unsecure content (in most browsers this means showing a warning symbol over the lock symbol at the left end of the browser’s address bar. There are some ugly workarounds for this involving various browser- and server-side scripts but I found it easier to find replacement images in ten or so cases that were hosted on secure pages.

Changing over the non-WordPress pages was pretty straightforward. I’m in the middle of redoing a lot of those pages anyway.

I was moved to do this because the slides.com tool I used to build yesterday’s presentation doesn’t much like serving insecure content, either. It made the editing process harder because I couldn’t easily see what I was working with and when I gave the presentation I had to do so with my browser’s security purposefully turned off. It’s not a big deal in the short run but over time it’ll be easier to just do it “right.” I updated the slides to reflect the new information and, as I think about it, I should also check the references to the site I’ve placed on LinkedIn and elsewhere. I also updated the settings in the FTP access tool I’ve been using.

Posted in Software | Tagged , , | Leave a comment