New TechTalk Update Coming

THIS is the update I’ve been waiting for since June. It’s clear, concise and informative. Please continue to keep us posted with these short-and-sweet updates. Thank you, @waytools! :+1:

4 Likes

Do you mean you want a “final assay” to assure quality and does the relate to the consistency of your magnetic parts?

We do an assay, but final assy = final assembly. That consists of snapping submodules and parts together, the electronic modules having all been built in Malaysia and Taiwan.

After final config of the submodules domestically, we then do a full integrated QA of the configured unit.

That QA is effectively an assay of the end-product.

4 Likes

I smell what your step’n dude. thanks for clarifying!

Very exciting. I was one of the first Treggers having ordered my TextBlade in March 2015! I loved it but left it in a plane seat pocket about 2 years ago and have been in mourning ever since (I keep my typing fingers dressed in mourning black).

To think that there is a realistic expectation of GR has my fingers dancing for joy.

The only sad thing is that when I checked for my original order the screen showed today’s date rather than March 2015. Maybe a Gremlin entered Waytools’ system. We all should check that those of us that ordered years ago, get to keep their place in line.

Sorry for the loss, @tskwarek.
There’s a new topic on the status page date change:

How goes it Waytools?

3 Likes

IPdude - thanks for asking. Busy with distractions on lots of admin responsibilities, but engineering on new infrastructure release is looking pretty darn good.

6 Likes

Glad to hear it. Could you elaborate a little? I mean, from your statement we don’t even know if it is hardware engineering, software engineering, or both, let alone what the progress is or what is remaining. No, I don’t expect extreme detail.

Oh, reread and you said “infrastructure release”. But that can still mean a lot of different things. Heck, it would be great if something could be said like, "The hardware and firmware are close to being done, but we need to beef up our infrastructure to handle mass shipping an support for customers before actual GR.

dbk - that’s the dev team’s new infrastructure code fork that I was referring to above.

More to validate for full feature parity, but what we already have locked and loaded is working meaningfully better than the release you’re using now.

4 Likes

Trying to remember how other things were described. I think maybe when you referred to stuff to make shipping and post GR support work better, you might have used “logistics” and I thought it was “infrastructure”.

So, “infrastructure” is about the code fork. Which brings us to:

I don’t suppose you can tell us the stuff that is better (or even as good since you previously said if it wasn’t for the problem of low free memory available, which would greatly complicate support, that the present version would probably have been good enough), that is up to snuff :slight_smile:

Or, conversely, what isn’t. Or both!

Right off hand, I can only think of one thing you have specifically said is better than before, and that was that jumps were about twice as fast.

You’ve made other comments about plans - which would be before or after GR was never clear - such as more jumps. More boundaries, etc. So those are some things right there that could be at least partially referenced.

If I was in a position to know and had to write an update, without taking much time, I might say:

Jumps are at least double the old speed and we don’t need any more improvement on that issue before GR.

We feel we have been able to create more jumps, however, the plan for now is to not turn on that ability until after GR out of caution that many people testing it in Treg could find a problem. So the intention is to do GR without those new jumps, but have treg users give them a workout in later betas first.

We have created the framework for a few more boundaries - those which seem to have the most need - but the present schedule will have those added after GR.

The ability to edit the shift keys now exists (useful for those to change a shift key if they only use one all the time now) and will be in GR.

We have also made it possible to assign modifier keys (also in combination) to a key without also requiring another key to it. IOW, you could turn the right shift key to be “command/control”, thus letting you just hit that one key and then whatever other key you need for a special action. Right now you’d have to hit three keys to do that so this will give more flexibility for those who need it.

Of course, all the above are just wild examples, based on things you’ve posted about here and there over the years. But if they all happen to be correct, you could just post, “You have everything right” :slight_smile:

1 Like

Considering how much you like to write on here, Mark should just give you a brain dump every 30 days and let you translate it into long rambling posts :wink:

If I had the info, my tendency would be to try to make a simple list of changes - and later write long posts discussing the importance of each! Or unimportance as the case may be.

2 Likes

@waytools, at least now can you give a percentage of features that have been ported to the new infrastructure fork enroute to feature parity with the latest TREG build? One number, that’s it - no explanations, no demand for detailed updates. I just want a number to put “making steady progress towards feature parity” in perspective.

2 Likes

Hrishi1379 - excellent, elegantly simple query.

Answer: More than 80% of all feature parity functionality has been migrated and validated.

New code subsystems are also showing meaningful performance gains.

Faster, stronger, cleaner code, and with more robust self-monitoring.

And super important - new code base is much easier to maintain and extend.

After user satisfaction was proved, we’ve focussed on making all inner workings rad-hard.

9 Likes

Good.

About the remaining 20%, obviously they aren’t at “parity”, but are any of them really causing problems to solve before being “good enough”? For example, all BT can have problems with interference, etc. But it seems that will not be completely solved since no one has done it. So that is an example of something that may still be an issue, but also be “good enough”. Or maybe not good enough if it isn’t as good as the prior version of the firmware.

Probably didn’t describe that well, but it’s the best I can do at 2:00 AM!

There’s an old saying in software development (and probably other areas as well) that 80% of the final results represent 20% of the total effort, while the remaining 20% of the results take the remaining 80% of required effort…

I’m not saying this is the case with Waytools/Textblade, but (more than) 80% doesn’t mean that we are near or far from GR in case anyone is expecting to get a timeline from reading between the lines (I’m not).

I’m eager to get my hands on the thing, yes (and as many others here, I also applied for TREG) but I’m on the bandwagon that only expects the blade to hit the shelves by 2021, solely based on my experience as a developer (and code seems to be the main work currently underway at Waytools).

And why would you insist on feature parity on a product that is 4 years late and never reached General Release?

Why isn’t 80% parity good enough for General Release?

Just like why would you scrap your firmware that from TREG reports was generally stable and worked.

How in the world does WayTools make business decisions? They make no sense to me.

I would be absolutely stunned if you answered any of the questions.

2 Likes

It all depends on the specifics.

There are 24 letters in the (English) alphabet. I would be 0% satisfied with a keyboard that nailed 80% of those but failed 20%. I just can’t imagine life without the letter ‘r’.

I’m 100%+ satisfied with my TextBlade test unit as-is. I’ll even tell you that’s an understatement.

But @waytools has explained clearly that there are business reasons that shipping the existing firmware is not a good idea from a general release and supportability point of view. They’ve said that this awesome enthusiastic response (much better than earlier firmware versions) proves to them that the feature set is great, but that they feel the need to provide that same feature set (parity) in a more sustainable architecture.

So they are making reasonable business decisions step by step. Us watching, without knowing all the factors, and with the additional benefit of several years of hindsight*, can second guess or disagree with those decisions without the need to say they are not making business-based decisions. I’ve always thought the Google model of an extended chaotic beta phase would have been an interesting and exciting way to launch and build up enthusiasm for Textblade even though problems and issues and crisis would have surfaced along the way. But even though I know slightly more than a non tester I know massively less than Waytools about all of the factors involved, including the hardware & production dimensions that were not a part of the google launch. More importantly I know that as a startup @waytools has ONE SHOT to get things right in terms of launching a successful business, and their choice of how to play the rollout game has to be between them and possibly any investors.

*Finally, it’s a total straw man to second guess Waytool’s decisions as if it was a preplanned multiyear extension program. No matter what your interpretation of the past few years it is abundantly clear that at each moment in time they were making decisions based on existing circumstances and the reality of the time it is taking to get it to a stage where they feel they can release it in the right way to the market is not the original timeline they had planned. In my opinion the idea that it was a premeditated plan from day 1 to have the sequence of events which occurred is really just conspiracy thinking.

3 Likes

I’m unsure why this is constantly asked. Just counting my posts, I’ve pointed out pretty much any time it has been brought up, good reasons why. Based on what WT has posted and adding my own extensions to their arguments.

People can, of course, disagree and I have no problem with that. What mystifies me is that the question keeps being asked without any counter argument to what has been presented.

So, here we go again:

  1. WT has said the present version worked well enough. However, that isn’t the only factor to be considered before GR.

  2. They also need to be able to provide effective support - which will, at the very least, involve code changes as the inevitable bugs are reported.

  3. The firmware changes to help support MAY include additional in-built testing and measurement tool even better than what we have now. They haven’t specifically said this, but it is certainly a possibility.

  4. The present firmware takes up all the available memory, thus they don’t have room for any improved testing/measurement stuff. But whether they need that or not, they DO need space for changing code. It’s very simple. With no free memory, it will often be the case that to fix one problem, they have to also rewrite something else just to make room. WT has specifically said this. But any time you change code, you might introduce a new problem. This is acceptable if you are fixing a bug. That is, you might fix one but create a new one in the same routine - an unavoidable risk. But when you are not only changing that code, but also other code, you are at least doubling the chances of creating a new problem!

  5. Which brings us to the argument that they should ship the old version while finishing the new one. Okay, I can see that point, but it also means they would be taking more time to solve problems as some people work on fixing the present version sent out in GR, while others work on the new version. Essentially trying to solve the same problems in two different sets of code.

I’m not going to say they made the best choice there. I have no idea. No one outside WT can possibly know. And even with all the info WT has, they may not really know what the “best” choice would be. But it is their choice to make.

Our choice is whether to continue with the risk of eventual delivery or not. Heck, I have two ordered. Sometimes I feel like making it 6. Sometimes I feel like making it 1. We all just have to decide for ourselves, including whatever you feel about the lack of a major update (which does annoy me!).

1 Like