A few bumps along the road of initial setup of the HEX-CAN

[PanEuropean]

A couple of weeks ago, I wrote a post with some comments about my first experience using the HEX-NET device. I had managed to set it up in 'access point' mode, but reached an impasse when the device wanted a firmware update, something that cannot be accomplished in access point mode. That post is here: HEX-NET Firmware Update: Just how is this task accomplished?.

Today, after waiting a week to rescue the device from my neighbors RS7, I got it operating in 'infrastructure mode'. Here are my comments about this whole experience. I'm not a computer wizard, but then again, I'm not a noob either. Below is a chronological list of what I encountered as I set the device up to work in infrastructure mode, then attempted to update the firmware, then attempted to log into VCDS-Mobile for the first time.

Defining Profiles
Once I grasped the concept of what was involved here, and after I went to the Ross-Tech website and used the search feature of that website to find the little Java application needed to set up the profiles, the whole process was not too difficult. The following thoughts occurred to me as I was doing this:

1) Why didn't this Java application (HexNetConfig) get automatically installed on my computer when I downloaded VCDS 14.xxx? It's not like it is the size of Adobe Creative Suite 6. Heck, it's tiny, and adding it into the big package that contains the VCDS application 14.x would not increase the size of the download by even 1%.

2) Why did I have to go digging into my computer using File Explorer to find this little Java application after I downloaded it? Isn't it possible to have a button somewhere on the "Port and Protocol Options" page that says 'Configure HEX-NET', and when I push that button, the HexNetConfig application would launch automatically? I mean, heck, I have to go to the "Port and Protocol Options" page anyway to carry out the communications test, it would sure make sense (to me, anyway) to have a push-button right there under the TEST button that says 'Configure HEX-NET'. What I am getting at is this: I think you should make it appear to the end user that the process of configuring the HEX-NET device is a function that is built into the VCDS application. Doesn't matter that this work is done in a separate Java app - just let me launch that app from within the main VCDS 'control panel', which is "Port and Protocol Options".

3) Got the Java application running. It opens in a really small window (previously discussed here: Suggestion for Human Interface Improvement of Wi-Fi Configuration Utility. In fact, that window is so darn small, it doesn't even present all the information that is contained in the window... the user has to stretch the window out (by dragging one corner with the mouse) in order to see the 'current active profile' message at the bottom.

Compare the first picture (Java window opens at default size) with the second picture (after I enlarged the size of that window). See the additional information at the bottom of the second window that was hidden in the default size window?

What the Default size window looks like



After the User Enlarges the Window by Dragging on a Corner


Note also that there is a layout error in the bottom of the second picture (above) - the text string 'Current Active Profile' is imposed on top of the variable (the number) that identifies the current active profile, in this case a 2. I think it would make more sense if that 'Current Active Profile' display was moved up and put directly below the 'Delete Profile' button. Also if instead of giving us a number, you gave us the name of the router, so the whole string read 'Current Active Profile is BELL932', rather than 'Current Active Profile: 2'. It would be simpler, more clear, less liable to oversight or misunderstanding to use plain language.

On the topic of 'plain language', what's the story on the 'profile prior...' label? Does that mean the profile I was using prior to this one? Or does it mean "Profiles in Order of Priority"? If the latter, then please spell it all out in plain language! Sure, you guys know what it means, because you live and breathe the code every day. We users don't understand - nor do we appreciate - truncated text or abbreviations and acronyms in place of plain, easy to understand language.

Eventually, I got to the screen below:


More acronyms and abbreviations. Rather than having a tiny (width-wise) box that contains an unidentified serial number and some things called 'CB' and 'FW', why not make the small box at the top the same size as the larger box underneath it (the one with SSID, etc.), and spell things out in plain language, as follows:

HEX-NET Serial Number: HN-1-000718
Code Block Version: 0.4102 API 4
Firmware Version: 0.176.1

You might think that is unnecessary, but just think of how many times your support people are going to be asking a customer "What's your firmware version?" or "What's your Serial Number?" and the customer is going to reply "I dunno, where is that information", at which point your support people are going to say "Well, look for the secret code letters 'FW', and that will tell you the firmware version, 'cause our programmers didn't want to type the extra 6 characters necessary to spell the word out in full".

Moving along, the next screen I saw was this one:


Consider that I am a new user, I'm still trying to figure out how to use this new-fangled wireless device with my traditional VCDS desktop program. I haven't even got to the point where I can use the device with the desktop version of VCDS (this because the device wants a firmware update), and now I'm asked to go do something entirely new, which is to use the VCDS-Mobile web-based application. OK, time to go back to the Ross-Tech website and search for a movie that explains what the heck VCDS-Mobile is.

It sure would be a lot easier if instead of looking like the picture above, the prompt to update the firmware looked like the picture below:


It would be even nicer if pushing the button in the picture above took me directly to the "Options - Check for Updates" page, instead of presenting me with the screen below, which contains an instruction to go find the "Options - Check for Updates" page myself.



What the heck is a 'dataset update'? Remember, I just launched VCDS-Mobile for the very first time, I haven't even got to first base on my attempt to update the firmware, and now I am getting another bit of information telling me that I might need to do a 'dataset update', whatever that might be.

Eventually, I got to the right place to download the firmware. But, once again, I'm presented with acronyms and abbreviations that detract, rather than adding, to the legibility and clarity of the information presented. Have a look at the image below. Why not write 'Firmware Update' at the top, rather than FW Update? Maybe I know what 'ETA' means (heck, I ought to, having made my living as an aircraft pilot all my life), but do you think every user - especially users to whom English is a second language - will understand 'ETA'? Why not change that label to read 'Time Remaining'? That would certainly make things more clear. If you really want to stick with aviation abbreviations, at least use the correct one, which in this case would be ETE (Estimated Time Enroute). An ETA is always a clock time, not an integer.



Eventually, the message below appeared. There's nothing at all wrong with my internet connection. I can tell that by looking at performance monitoring in Task Manager, or by simply going to a web page in a browser. This message is spurious.



Should the 'Cancel Update' button at the bottom of the picture above still be present (active, not dimmed out) at this stage of the game? Like, if the device is already rebooting, could I still cancel the update? I kind of doubt it, so, maybe best to get rid of that 'Cancel Update' button once the device starts to reboot.

Next, the screen below appeared. I've already had one ball thrown at me from out of left field (needing to go to VCDS-Mobile when I was in the process of trying to update the firmware), now here comes the second ball out of left field.



What if I don't happen to have a vehicle handy? What if it is the middle of winter, and I don't have an indoor garage? Is it possible to accomplish this by connecting the device to the computer using the USB cable that you provided? If so, that would be a heck of a lot easier way to do it. After all, all of these activities we are discussing are 'first day of use' activities, it is reasonable to assume I still have the shipping box and the USB cable with me.

(message continued in next post, this due to the 10 image per post limit)

 

[PanEuropean]

(continued from post above)

What would be nice would be a button to push that would take me directly to 'Cloud Functions' to do this work. Like below.



In fact, if it is possible, it would have greatly simplified things if the first instruction I got way back at the beginning of the whole process was "Connect your device to your computer with the cable in order to set up Wi-Fi profiles, update firmware if necessary, and register your device with Ross-Tech".

Well, I managed to get connected to the VCDS Cloud. Guess what the first thing I saw was... a message from my browser (Chrome) telling me that not everything is military-spec with the connection to the cloud. Heck, I'm running the latest version of Chrome, and the latest version of Windows 8.1 SP1. At this point, I just want to get all this procedural work done so I can use the new device (in the traditional manner, with VCDS on my laptop - I never asked to have anything to do with Clouds), so I decided to live dangerously and I dismissed the security warning (image below).



Finally got to the cloud. It must be a cumulonimbus cloud, with considerable upward lifting of unstable elements within the cloud taking place, because one of the balloons has been lifted upwards and superimposed over a block of text. Let's hope it doesn't turn into a thunderstorm before I get finished and get out.



-----------------------------------------------------------

All in all, it was a somewhat frustrating and certainly discontinuous process. I still don't know if my firmware got updated or not... I tried that process a couple of times, and saw two different descriptions of what the changes in the firmware comprised. It would be nice if in one of those Java windows there was a little box that said "Current Version of Firmware: 1.2.3 Version of Firmware on your Device: 1.2.3" If that information was provided, I would know if I had the most recent firmware.

I have been a bit sarcastic in this post, but my heart is in the right place, because I sincerely believe that you folks have got to make the whole "initial setup" process a lot simpler and easier, otherwise, your phones are going to start ringing off the hook once this product comes out of beta.

I suggest that you provide a written document inside the box that explains the new concepts that this device introduces, for example, Wi-Fi connectivity either by Access Point or Infrastructure Mode (with a brief explanation of the advantages and disadvantages of each mode for the technician who has bought the device), using the device 'traditionally' with the Windows desktop version of VCDS vs. using the device 'via the cloud', and also a clearly written walk-through of what the user will have to do on the first day to get up and running:

1) Configure Wi-Fi Protocols
2) Check for Firmware Update
3) Connect to Ross-Tech and register device
4) Download new datasets
5) Decide whether to use the device with a PC, or via the web interface to VCDS-Mobile/Cloud
6) Any other setup tasks that might be necessary

I am willing to write a draft of such a setup manual. It'll cost you lunch next time I come by your neighborhood. Let me know if you would like me to send you such a draft.

Michael

 

[Uwe]

1) Why didn't this Java application (HexNetConfig) get automatically installed on my computer when I downloaded VCDS 14.xxx?

It did. It's been in the VCDS Beta 14 distro since the beginning. Start -> All Programs -> VCDS-Beta -> HEX-NET WiFi Config.

2) Why did I have to go digging into my computer using File Explorer to find this little Java application after I downloaded it? Isn't it possible to have a button somewhere on the "Port and Protocol Options" page that says 'Configure HEX-NET', and when I push that button, the HexNetConfig application would launch automatically?

I suppose we could do that. In order to avoid clutter and confusion among customers who don't actually have HEX-NETs, my temptation there would be to only show that button if VCDS finds a HEX-NET connected via USB.

3) Got the Java application running. It opens in a really small window [...] the user has to stretch the window out (by dragging one corner with the mouse) in order to see the 'current active profile' message at the bottom.

We'll have to have a look at that. Something tells me the machine you're running on has some of the font/screen scaling set in a somewhat unusual way.

Eventually, I got to the screen below:


More acronyms and abbreviations. Rather than having a tiny (width-wise) box that contains an unidentified serial number and some things called 'CB' and 'FW', why not make the small box at the top the same size as the larger box underneath it (the one with SSID, etc.), and spell things out in plain language, as follows:

HEX-NET Serial Number: HN-1-000718
Code Block Version: 0.4102 API 4
Firmware Version: 0.176.1

Good point.

It sure would be a lot easier if instead of looking like the picture above, the prompt to update the firmware looked like the picture below:

I like this idea -- if we have the IP address handy (meaning we're doing it via WiFi). The catch is that's an MFC MessageBox, which isn't very flexible; but I'm mulling over ways to do something like that.

Eventually, the message below appeared. There's nothing at all wrong with my internet connection. I can tell that by looking at performance monitoring in Task Manager, or by simply going to a web page in a browser. This message is spurious.

Yes, it spurious. I've complained about that one numerous times myself. It hasn't happened as often recently, but it still happens sometimes.

 

[Uwe]

Next, the screen below appeared. I've already had one ball thrown at me from out of left field (needing to go to VCDS-Mobile when I was in the process of trying to update the firmware), now here comes the second ball out of left field.

[

What if I don't happen to have a vehicle handy?

Then a Cloud account isn't really necessary right now.

No, seriously, I've raise the same point; that it should be possible to create a cloud account (or associate an interface with an existing account) without being connected to a car, but the way the server authentication stuff is implemented right now, it's not easy to do that, so it's been deferred for a while.

Well, I managed to get connected to the VCDS Cloud. Guess what the first thing I saw was... a message from my browser (Chrome) telling me that not everything is military-spec with the connection to the cloud. Heck, I'm running the latest version of Chrome, and the latest version of Windows 8.1 SP1. At this point, I just want to get all this procedural work done so I can use the new device (in the traditional manner, with VCDS on my laptop - I never asked to have anything to do with Clouds), so I decided to live dangerously and I dismissed the security warning (image below).

SSL certificates are a funny thing. You can generate them yourself. In that case, nobody has the root public key except you and nobody can masquerade as you and thereby intercept your data, but then browsers claim the certificate is "Untrusted". The alternative is to buy a certificate from a Certificate Authority. This does away with the "Untrusted" message from the browser, but then you have assume that the CA's root key IS in the possession of certain elements who CAN masquerade as you and thereby intercept you data. I think Orwell would be proud of this definition of trust -- the browser is basically telling you, "I don't trust that the Big Brother has the root key".

But we'll probably put a commercial certificate on the cloud server before we go out of Beta.

Finally got to the cloud. It must be a cumulonimbus cloud, with considerable upward lifting of unstable elements within the cloud taking place, because one of the balloons has been lifted upwards and superimposed over a block of text. Let's hope it doesn't turn into a thunderstorm before I get finished and get out.

Yeah, I've seen that once or twice myself. Unfortunately, I haven't been able to make stuff like that appear on demand.

I have been a bit sarcastic in this post, but my heart is in the right place

I know it is. Feedback like this is one of the reasons you have a HEX-NET despite not being a "US Customer".

I suggest that you provide a written document inside the box that explains the new concepts that this device introduces, for example, Wi-Fi connectivity either by Access Point or Infrastructure Mode (with a brief explanation of the advantages and disadvantages of each mode for the technician who has bought the device), using the device 'traditionally' with the Windows desktop version of VCDS vs. using the device 'via the cloud', and also a clearly written walk-through of what the user will have to do on the first day to get up and running:

1) Configure Wi-Fi Protocols
2) Check for Firmware Update
3) Connect to Ross-Tech and register device
4) Download new datasets
5) Decide whether to use the device with a PC, or via the web interface to VCDS-Mobile/Cloud
6) Any other setup tasks that might be necessary

I am willing to write a draft of such a setup manual. It'll cost you lunch next time I come by your neighborhood. Let me know if you would like me to send you such a draft.

I think I can offer better stuff than just lunch.

-Uwe-

 

[jyoung8607]

SSL certificates are a funny thing. You can generate them yourself. In that case, nobody has the root public key except you and nobody can masquerade as you and thereby intercept your data, but then browsers claim the certificate is "Untrusted". The alternative is to buy a certificate from a Certificate Authority. This does away with the "Untrusted" message from the browser, but then you have assume that the CA's root key IS in the possession of certain elements who CAN masquerade as you and thereby intercept you data. I think Orwell would be proud of this definition of trust -- the browser is basically telling you, "I don't trust that the Big Brother has the root key".

That is not quite true. You always generate your own certificate. What you buy is a cryptographic signature on it from a trusted third party (technical terms here, set aside Big Brother for the moment). Assume that Alice trusts Bob, and needs to talk to a new acquaintance Charlie:

Edit: In retrospect I may have misremembered the order of events in CA signing, and whether the CA posesses the private key in the end, but the trust model still is what it is.

Self-signed certificate: Charlie tells Alice, "I am Charlie" as a pretty bare assertion. Alice can take it or leave it.

CA-signed certificate: Charlie tells Alice, "I am Charlie, Bob says I'm cool" in a cryptographically provable way. Alice trusts Bob, and can therefore trust Charlie.

Anybody in the world can make a certificate that asserts it is "vcds-cloud.com". I can do that right now. The user's browser realistically has no way to evaluate that and say one is better than the other. Theoretically your Verisigns of the world do a little more verification before signing. What if one of your browser's trusted CAs is compromised, or served with legal process? You're screwed anyway. A false CA-signed trusted cert would be trusted by the browser over a self-signed cert. It's happened, but mainly for high value targets. Unless you start doing e-banking through VCDS, or a government starts having a problem with you diagnosing cars for Al Qaeda, this is not a realistic threat. CA signing isn't perfect, but it's always better.

But we'll probably put a commercial certificate on the cloud server before we go out of Beta.

Cool.

Yeah, I've seen that once or twice myself. Unfortunately, I haven't been able to make stuff like that appear on demand.

The same sort of thing was consistently happening to me before I got through registration. If there's a way to zap my unit back to factory-fresh unregistered, I could try to reproduce it again. Is that possible? If it happens again, I could arrange some NAT holes for you to hit it directly and look.

Jason

 

[jyoung8607]

It did. It's been in the VCDS Beta 14 distro since the beginning. Start -> All Programs -> VCDS-Beta -> HEX-NET WiFi Config.

I missed that as well as Michael. I had ass-u-med it was separate, because I got linked to this page at some point:

http://www.ross-tech.com/hex-net/downloads.html

... on which the utility is delivered separately. I realize you need to do that for OSX and Linux, but in fairness to myself and Michael, there is no mention it's embedded in the VCDS Desktop as well. I've been using a separate copy. I use Windows 7 or Windows 8 with Start8, and I'm used to hitting Windows key and typing "VCDS", so I've never seen the program group.

I suppose we could do that. In order to avoid clutter and confusion among customers who don't actually have HEX-NETs, my temptation there would be to only show that button if VCDS finds a HEX-NET connected via USB.

+1 Cool thanks!

I like this idea -- if we have the IP address handy (meaning we're doing it via WiFi). The catch is that's an MFC MessageBox, which isn't very flexible; but I'm mulling over ways to do something like that.

+1 Cool thanks!

Jason

 

[PanEuropean]

Hi Uwe:

Thanks a lot for taking the time to read my comments and respond to them. I really enjoy the process of debugging and fine-tuning the man-machine interface (the Human Factors aspects) of complex software.

I have no objection to any of the proposals or responses that you made... I think you and I are pretty much reading off the same sheet of music.

After I wrote that rather lengthy post yesterday, I started to think about what the easiest way (easiest for both Ross-Tech and for the end user) to completely carry out the initial setup of a new HEX-NET device might be. The more I thought about it, the more the concept of a 'dedicated initial installation and setup application' for first-time HEX-NET setup became attractive. By 'dedicated initial installation and setup application' , I mean an application that is basically an installer on steroids, an application that would ask the user questions (or query the user's computer to find the answers to questions) in a logical sequence, then proceed onwards with all required aspects of setup, configuration, login, and testing by Boolean logic depending on the answers to the questions. Apple makes their new hardware do this kind of thing the first time it is turned on, Microsoft does pretty much the same thing when a user installs one of their operating systems for the first time, etc.

Here's a 'back of the napkin' outline of how I could see this working. Keep in mind as you read through this that I am a 'soft goods' specialist (Human Factors specialist), not a 'hard goods' (programming and coding) specialist. But, what I am proposing is something very similar to what I did together with Honeywell Aerospace when I wrote the specifications for the fully integrated avionics system user interface on the 19 passenger regional aircraft that I was responsible for.

1) The user would download a new VCDS software package (for example, VCDS version 15.x) in the same manner as they always have, and initiate the installation in the same manner they always have. The present installer engine would present the usual licence agreement, copyright notices, and so forth. Once those formalities were out of the way...

2) The installer would look for existing evidence of a HEX-NET device having been used on the target computer. If no evidence of prior HEX-NET use was found, the installer would install a driver for the HEX-NET that would be able to detect a HEX-NET on first connection (USB or Wi-Fi).

3) The first time a HEX-NET is detected as being connected to the computer (by USB, or by access point login, or by query from the target computer while in infrastructure mode), the installer would launch the 'dedicated initial installation and setup application' for first-time HEX-NET setup.

4) The first thing that the 'dedicated initial installation and setup application' (let's call it the DIIASA for short) would do is ask the user to connect the HEX-NET to the computer using the USB cable, if this has not already been detected as having been done. Then, the DIIASA would ask the user to plug the device into the OBD port of a comparable car. In other words, the physical configuration would be laptop computer -> USB cable -> device -> automobile. This would ensure that 100% of the 'physical setup' (internet connection, car connection, USB connection) necessary for all of the subsequent tasks to be carried out gets put in place before carrying on with the rest of the 'interview and setup'.

5) Next, it would check for the presence of an internet connection (for example, ping Ross-Tech.com). If no internet connection was available, the application would ask the user to establish an internet connection on their computer by whatever means they normally do that - Wi-Fi, Ethernet, modem, tethered cell phone, whatever.

6) Once the internet connection was confirmed to be operational, the DIIASA would check to see if a firmware update was available for the HEX-NET, and also check to see if a software update was available for VCDS. If either one was found, the application would advice the user that update(s) were available and strongly recommend that the user press the "Download Firmware Update" and (if necessary) the subsequent "Download Software Update" buttons that would be presented. The DIIASA would continue to run through the update process, in other words, it would not shut down or exit while the updates were being carried out. It might, for a little while, get pushed into the background if that is necessary.

7) Once the updates were installed, the DIIASA would ask the user to enter the default password, then prompt the user to change the password to something unique but easily recognizable. You could include in the dialog box a brief explanation of why a password is needed ("to prevent other HEX-NET users from accidentally connecting to your device"), and perhaps suggest that a simple password (your Mom's home phone number, your girlfriend's birthday, your customer account number with Ross-Tech) would probably be sufficient for most users. In other words, the user doesn't need to kill themselves to come up with the same level of password security as they need for their bank account or income tax return. You might also want to protect your company by telling the user not to use the same password that they use for any privacy-critical service (like a bank account, credit card, etc.) because Ross-Tech doesn't want to be put in the position of possibly - no matter how remote the possibility may be - knowing what a user's favourite password or password hash is.

8) Next, the DIIASA would register the device (serial number, user name, user email, and perhaps even a password hint) with Ross-Tech.

9) The user would then be advised that the device can work in two possible modes: Access Point (for users with no wireless router, or for users who want to use the device at those Friday night GTGs in the shopping mall parking lot where no wireless router is available), and Infrastructure Mode (enables use of the VCDS-Cloud facility, and might offer greater range within a large facility such as a dealership service department). The Java app for wireless configuration would then be launched alongside the DIIASA, and the DIIASA would prompt the user (by way of text and screen-shot illustrations) through the various actions that need to be carried out using the HexNetConfig Java app. The user would be offered the possibility of setting up connections (profiles) to more than one router if they wish to do so.

10) Once wireless setup is complete, the user would be asked if they want to set up VCDS-Mobile at this time. Chances are that many users really won't have any interest in using VCDS-Mobile, at least, not on the first day... I expect that most users would be better served by first being allowed to get used to using the HEX-NET with the traditional VCDS application running on a computer, and maybe deferring playing around with VCDS-Mobile until they are comfortable using the HEX-NET device with the traditional computer-based VCDS application. (For what it's worth, I can't imagine me ever wanting to use VCDS-Mobile... heck, why would I want to squint at an index-card screen on a mobile phone when I have 10 years experience using VCDS on my laptop computer?)

11) Once the VCDS-Mobile setup is done (if the user elected to do that), and the user has successfully connected to the HEX-NET device via a web interface, most of the work is done. What remains is not much more than just 'setting preferences'.

12) The user would be asked if they want a shortcut to the VCDS application put on their desktop, and, if they are running Windows 8 or greater, a tile for VCDS placed on their start screen. If they set up VCDS-Mobile, they would be asked if they would like a shortcut to that placed in the bookmarks folder of their web browser.

13) The user would be asked if they would like to rescale the VCDS application window to a larger size, and if they answer YES, they would be directed to the appropriate control on the VCDS configuration page.

14) The user would be asked if they would like to have a PDF copy of the VCDS user manual downloaded and placed on their desktop.

15) The user would be asked if they would like a shortcut to the Ross-Tech forum added to their browser bookmarks bar. If they answered YES, not only would the shortcut be placed there, but the forum registration would be automatically carried out (all the user would need to provide is the desired username and desired forum password), the DIIASA already knows their device serial number and would authenticate them as a 'verified user' automatically.

I'm sure that there are other one-time setup and configuration tasks that an intelligent installer could be programmed to do using Boolean logic. I just can't think of any more at the moment...

Anyway... all the above is presented strictly as "food for thought", a "back of the napkin sketch" - something that might get your programming team thinking about how to simplify and automate the entire setup process, to make it as fast and easy as possible for the user to get up and running, and to dramatically reduce the number of phone calls made for new product support.

Michael

 

[romad]

Michael, it must be a Windows thing. On my Mac running Mac OS 10.7.5, after launching the Java applet, the first window I get is the 3rd one in your message. Clicking on the "Configure WiFi" button takes me to the 2nd window in your message; enlarging that window is useless as there isn't anything after the "Current Profile" line.

 

[Uwe]

The same sort of thing was consistently happening to me before I got through registration. If there's a way to zap my unit back to factory-fresh unregistered, I could try to reproduce it again. Is that possible? If it happens again, I could arrange some NAT holes for you to hit it directly and look.

This has been in my queue to answer since the other night. You may be on to something there with the possibility that this only happens when a HEX-NET that isn't associated with a cloud account yet; that would explain why we basically never see it. I'll have to ask the guys to try with some unregistered ones. If that allows us to reproduce it, we should be able to fix it.

-Uwe-

 

[jyoung8607]

This has been in my queue to answer since the other night. You may be on to something there with the possibility that this only happens when a HEX-NET that isn't associated with a cloud account yet; that would explain why we basically never see it. I'll have to ask the guys to try with some unregistered ones. If that allows us to reproduce it, we should be able to fix it.

I think I concur with this. My cloud connectivity has been generally bumpy (for reasons we talked about elsewhere), but the only time I ran across browser/display layout bugs was during the registration process.

Jason