The Ideal Mouse WishList

Given the supposed merging of iOS and OSX, given the apparent change from using Intel CPUs and transitioning to Apple CPUs (most likely ARM derived), I’m expecting some VAST changes to the entire UI paradigm on Apple products in the next two years, beginning most likely at WWDC this year.

Interesting times folks - interesting times. :slight_smile:


1 Like

Hmm, I’m fine with Macs switching to ARM, I do hope they don’t change the Mac UI (e.g. touchscreen instead of touchpad), or lock down the OS (e.g. no terminal access).

Awesome posts here, thanks! Lots of really interesting wants, and related considerations.

Confirm goal is not just super portability, but a pointer users actually prefer. Best of breed quality.

Post-GR, envision something really cool here. Better pointer totally achievable. Intrinsically simpler scope too.


I’ve had Macs for 10 years at least, but if it doesn’t function as a development workstation anymore, it’s not for me.

1 Like

@waytools I’m relieved to see you replying to this topic on April 3rd. I was slightly suspicious about the April 1st post, but now fascinated to see what ideas you come up with!


I find I almost can’t model without one now that I use one regularly, so maybe it’s good that you haven’t gotten used to it! Especially since the Swiftpoint GT is my go-to mouse because of a shoulder injury, and it really doesn’t handle the middle button well.

I would love a compact, jump-enabled mouse that had at least the three physical buttons and some sort of scrolling solution, whether that was a touch sensitive area, a pressure sensitive button like a track-point, or some better solution. It seems critical that none of those functions are blocking, for example, often modeling systems have a way to use the right or middle button to orbit the model, but the swiftpoint GT’s two buttons pressed at the same time doesn’t allow you to continue whatever function you had started with the left mouse button while middle clicking to orbit.

Of course, some innovative way to trigger 6DOF movement in the same mouse that you are using for regular functions would be outstanding, but a solid, jump-enabled, three-button-plus-scrolling mouse would be awesome.

I also like the idea of the mouse having something similar to the nano stand form factor for use as a case for the text blade.

On the other hand, since the touchpad might be the way to go for most users use cases, maybe you could put the touchpad in the “V” above the keys on the textblade? Without three rows above the home row it seems plenty close enough for moderate navigation and window placement (from what I can see from TREG pictures).

Currently, I think the trackpad is the way to go and Apple has that pretty much nailed. Not sure it’s going to get a whole lot better.

So then I started thinking, what could Waytools work on that no other company is capable or willing to do? If you weren’t restricted to improving current devices, what would you do?

What about eye tracking? Create a sensor bar that could clip to the top of your laptop, ipad or other device that tracks eye movement and pairs with the textblade.

There are a number of issues to work through, I’ll list as many as I can think of below, but the ultimate goal is that you would never have to take your hands off the textblade and the “eyeblade” (probably not the best name for it) could also magnetically clip to your textblade, making the entire package extremely portable.

This would require a textblade with some expanded key functionality since I don’t think you could use eye tracking for all pointer movement.

Scrolling: would be terrible to scroll with eye movement. Instead, use the spaceblade to scroll. Add capacitive touch so that you can gesture on the spaceblade for scrolling, simple swipe gestures, etc.

The next issue is dealing with large vs small pointer movements. I think it would easy and intuitive for quick, large pointer movements - jumping the pointer from one side of the screen to the other. But then you would need a modifier key on the textblade to adjust the sensitivity of the movement so you can make smaller, fine movements. Of course this may get annoying, pressing and releasing a key constantly to adjust the sensitivity of pointer movement, even if your hands are always resting near that key. Or it may just become second nature. Not sure.

You would also need keys to handle left/right/modified clicking. Unless you can add facial expression tracking… but not sure I want to look like a spazz making facial ticks at my computer.

Additionally, you would need to be able to pause cursor movement so as you look over a document, video, etc. the pointer isn’t swinging all over the place.

And of course the big one. Interpreting eye movement and filtering out the “non-intentional glances”. When you look up from your screen it would be nice if the pointer doesn’t shoot up to the top of the screen. Not to mention the constant eye saccades.

However, with Waytools years of experiencing refining the textblade’s ability to filter for intentional vs unintentional key presses this may give them a better chance than anyone else for building the necessary sensors and algorithms for determining intentional eye gaze.

Again, I have no idea if this would be pleasurable and better to use in the real world vs all the other pointing options but I figure it’s worth thinking about.

1 Like

How would you envision jumps working? Would you put a sensor on every screen?

I’m not criticizing, just asking. I imagine if it worked the way you wanted it to it would be pretty cool.

Honestly, I hadn’t thought about jumps. I haven’t received a TREG invite so I’m not automatically in that mindset :slight_smile:
If you have two devices where their screens are next to each other, then I suppose there may be a way to train it to work on both.
Perhaps when it first connects it displays a series of dots at different positions on the screen and when you look at them it learns the position of the screen relative to your head. It would have to be quick, just a couple seconds.
Perhaps there could be a preference where you can specify “fixed position” devices such as your laptop or work desktop where your head will always be in the same position relative to the screen so it doesn’t have to calibrate every time. Then other movable devices would be calibrated quickly each time you start a new session.

But back to the main question, if you have screens that are not near each other then you would have to have multiple sensor bars.

1 Like

I think what would make sense is a single sensor bar on a nearby screen. It SHOULD be able to determine that you are looking at distinct places based on your head and eyes. That way you wouldn’t need multiple sensors.

Now as to how to calibrate (i.e. a single time or each time) would have to be worked out. I suspect you’d need to do it each time your physical configuration changed. Even if you arranged them in the same order one time to the next there would likely be minute angle and positional changes that would impact the configuration unless you re-calibrated.


1 Like

Like others here, I was excited to see this thread and the implications it seems to bring (GR happening soon?!?), but I didn’t want to just jump in and give my two cents. I figured I need to give it some time for the question to sink in and really come up with the best idea.

Like others, I would really like to keep my hands on the keyboard as much as possible. So, some sort of marriage of the textblade and a pointing device seems like it would be best.

My first thought (like @Jesse_S mentioned) was to put a track pad in the space above the keyblades, but I had that thought when I wasn’t near my textblade. After sitting down at it and trying to see what it would feel like to try and touch a trackpad above the keyblades, I found it to be uncomfortable. It’s too much of a stretch (and one of the reasons why they engineered the textblade to pull down the numbers onto the top keys).

I then thought, maybe they could put one of those nub things like they used to put on the old IBM ThinkPads (oh, that’s called a Trackpoint) right in the center between the keyblades. However, I quickly dismissed that idea. I can’t imagine those being very precise. I never had a ThinkPad and only maybe used one once trying to help someone with their computer.

So then I tried to think about what I do now with my beloved Apple Trackpad (not one of those new ones, but one that actually clicks down when you push it). I move the cursor around with my right index finger, and if I need to click on something I either tap or press down to click depending on my mood (though like I said, I like the physical click). If I need to click-drag something, like a window or a file, I use my right thumb to click down and my right index to move the object. I do the same right-thumb-click, right-index-move operation in apps like Photoshop. It serves me well.

So, if that’s how I use a trackpad, how could I translate that to the textblade? Well, I already use my right thumb for hitting the spaceblade, so perhaps that should be the mouse click. And my right hand (and thus my right index finger) is already resting on the right keyblade, so maybe that could be my trackpad surface. I would just need some way to make the textblade know I want to move the mouse. Well, we already have precedent there too with all they chords for edit/select/ctrl/alt/cmd/etc. so why not just have another chord for telling the textblade that I want to control the mouse. Maybe like holding down WER (three fingers) or QWER (four fingers).

So, my proposal would be to just use the Textblade … no new hardware (or at least nothing visible, there may need to be some changes internally). So, you would activate mouse mode with a chord, use the spaceblade for the mouse button (could even support primary, secondary, tertiary clicks depending on where you pressed down on the spaceblade), and use the keyblades as the trackpad surface. One finger for moving around, two fingers for scrolling, etc.

Now, I know there isn’t much surface area on a keyblade, especially compared to the massive trackpads they are putting in macbook pros these days, but it seems like it would be fine, you may just have to pick your index finger up a few more times to move your cursor all the way to the top or bottom of the screen. I suppose you could have an alternative mode that just used the YUHJNM key for movement and have the cursor move faster the closer your finger gets to the edge (sort of a mix between the Trackpoint mouse and an Analog Joystick). That might work, but would take some getting used to.

Anyway, I know that this isn’t a completely new idea, that it’s been proposed before, but it seems like all the elements are there. It would at least be something to experiment with.


Some info from the past that deals with the space blade as track pad issue (from WayTools):

BTW, while I think a trackpad fits in with the TextBlade better than a mouse, there is no reason both couldn’t be done.


I’m wondering if maybe a larger space blade is all it would take, with more vertical space. Granted, the device would become bigger, but maybe it could be a “two high” space blade so the only difference would be our “pack of gum” would become “one stick thicker”. :slight_smile: what I mean by two high is that it would be like two space blades right next to each other horizontally so as to give enough vertical space for it to be a track pad. The bottom one might not need the “key press” ability, and would only be touch/track sensitive?


1 Like

I envisioned a possibility for two “space blades” so you could stack them, but in use, one would be placed below the other to double the vertical size. Of course, the touch capabilities of the present blade would have to be different too.

But I see possible problems with this approach, besides the fact that you would be crossing a gap, even if really tiny. The lower of the two blades would be too low for using as space. But with it there, you could have all sorts of issues when you hit the upper one for space and hot corners.

So, I’m still thinking a separate trackpad which, yeah, you have to move out of position to access, but if it is above the key blades or further below the space blade so as to not interfere, it could still be more convenient than reaching further away for a mouse.

Also, if they redesign the space blade to have the touch abilities needed for a trackpad, as WT has mentioned, there is still the very limited vertical range. But maybe my idea of using the keyboard as a trackpad modifier could help - just as an example, suppose holding A/S activates track pad mode and you can move the cursor around as you move your finger. But then, if you hold A/S/E, the vertical motion is double the cursor motion for the same amount of finger motion.

I have no idea if the movement would be something that people would easily adapt to or not. After all, you’d be moving faster vertically than you would horizontally. Something I’d just have to try to know about. Sort of like how I had to actually use the TB edit keys to see how well they worked in a short time.

1 Like

If the eye tracker could track the devices as well it might not need recalibration. I know this isn’t easy, but logically not impossible.

Simple solution here would be to have the A/S/E chord increase cursor motion in both the vertical and horizontal. It would at least get rid of any confusion.

1 Like

Yeah, I thought of that but just got to thinking a non-intuitive approach could work. After all, that small vertical area is unavoidable but the horizontal is fine. So I thought the increases vertical movement may be better than than repeated swipes even though it may be more reactive than people prefer in fine control. So I wanted to avoid the negative aspect in the horizontal. It’s just one of those things I can’t tell without being able to try different approaches on a real device.

I keep seeing almost everyone so far asking that the mouse/trackpad/laser discombobulator or whatever name and/or form this takes should also change devices with the TB jump function. I don’t know if this is how it should work. If this was an option, fine, but I don’t think it should automatically be tied to the jump.

As it stands now, I can jump to my iPhone or my iPad, neither of which accepts mouse input. Why would I want the mouse to jump to these devices that can’t use it? What if I’m doing something on my Mac/Windows/other machine where I would like to keep mouse input tied to that device but decide to jump to iOS to make a quick note? I may want to use the mouse on one device while I use the TB with another. This would require a separate jump for the mouse, or the ability to configure jumps so that if I jump to an iOS device, the mouse input remains with the last used compatible device. Then, if I jump to a different mouse enabled device, the mouse input should move to this new device as well as the TB keyboard input. But maybe, sometimes it shouldn’t. See where the problems arise?

I guess my point is, I can foresee situations where I WOULDN’T want the mouse to jump with the TB and other situations where i always would and still others where I might want it or might not. I can’t be the only one, am I?


That’s a nice refinement, thanks JMacRury.