Fairberry project brings a hardware keyboard to the Fairphone Hardware hacker's non-trivial project to weld a Blackberry keyboard to an Android fondleslab is being updated with an off-the-shelf PCB. The Fairberry project has an ostensibly simple goal that's harder than it initially sounds: building a housing to physically connect an off-the-shelf Blackberry keyboard to an Android phone, …
Same here - although I do still have mine, in the time capsule/box of old tech stuff I keep around.
If someone came out with a modern equivalent, I'd buy it in a heartbeat - even after all these years of having no other real choice, I still loathe touchscreen keyboards. I also never really got on with the Blackberry keyboard, landscape QWERTY is what I'm after.
[Author here]
> I also never really got on with the Blackberry keyboard, landscape QWERTY is what I'm after.
This is what was unique about the Passport: the square screen meant it was effectively always in landscape mode. It's the only Blackberry keyboard I found usable, and the fact that the metal strips between rows of keys also meant that it was able to support scrolling gestures was a huge win.
I had an experiment with an old Q10 last year. Step-father has badly arthritic hands and really struggles with touch screens. His fingertips no longer point in the same direction as his fingers. Plus when you're in your mid 80s the skin is much less conductive anyway - which really doesn't help with capacitive screens.
So he bought a new old-stock Q10 from a Chinese vendor on Amazon. Which won't work if your network has already turned off 3G - and anyway is a decade old now. But before I'd realised that and got him to send it back, I got to play with it. And the keyboard is truly amazing. I still hate them, due to my fat fingers, but that thing was a beautiful piece of engineering.
But I did find him the Unihertz Titan slim linky to their site - which is surprisingly nice. Not exactly the most up-to-date version of Android - and the keyboard is rather decent, but nothing close the excellence of the old Blackberries. On the other hand, it's a £250 mid-market Droid, not a £500 premium phone - as the Blackberries were at the time. Keys are a bit bigger, though not as ergonomically sculpted - and they have even bigger models, with bigger buttons.
The important thing is he's happy. Me, I dislike onscreen keyboards slightly less than I do these tiny physical ones, so I put up with an Android. Swype makes onscreen keyboards a bit more bearable.
I used to have the Sony Ericsson P800. Where the keyboard was a number pad with actual pins in the back, so when it was folded over the screen it literally pressed the touch screen to operate the keys. Proerly primitive. The onscreen keyboard was so small you needed to use the stylus anyway, so you might as well use the handwriting recognition. So the P910i was positively advanced when it came out. But I didn't get one. I got a Motorola Razr instead, on the grounds that these modern smartphones were overrated. And I didn't reconsider until after the iPhone had come out and HTC had begun making nice Androids.
Happy weird early century phone memories. There were some strange old designs out there.
I still have two. I bought one off eBay when my original no longer worked (i repaired the SIM holder a few times, but eventually other things broke) but then its replacement too eventually suffered the doom of what I assume must have been early lead-free soldering
The best thing about it for me, (aside from the keyboard which was a dream to use compared to modern phones that make you feel as if you've had nine fingers amputated) was that it ran a native Debian-based OS that accepted arm debian packages. It could run many GTK and Qt desktop apps natively including things like Mumble (discord-like voice chat). You didn't need a hulking proprietary SDK to develop software for it. And since it ran X Windows, I could even run full-fat desktop Matlab, via an SSH tunnel to my university's Linux cluster.
And the browser had *Text Reflow*. With hardware zoom buttons.
[Author here]
> it ran a native Debian-based OS
I initially thought you meant two Blackberry Passports, but the quoted line means you can't have done, because BB 10 devices don't run Linux at all. They run QNX, an unrelated microkernel OS that's older than Linux, and a custom GUI based around Qt. (Presumably related somehow to QNX Neutrino, but I don't know the details.)
I don't recall any way to get to a shell on BB10 but I would not expect it to understand Debian packages, let alone run them.
Yes.
I left mine on a train and never saw it again, despite returning to the terminal station literally only minutes after arrival. I suppose it might still be doing service for someone.
Oddly enough, despite having stumpy fat fingers I preferred the keyboards on the PalmOS devices I had previously. Even the tiny Centro. But any of them was better than a touchscreen virtual jobby.
-A.
Similarly, I really miss my Nokia E7: on the surface seemingly just an ordinary touchscreen phone, but, with just a gentle magical nudge of your fingers, you could slide the screen back and up at an angle to reveal the keyboard underneath, and end up with something sort of like a modern-day Psion 5mx…
...oh man, that brings back memories. A mate had one and for the half hour or so I got to mess with it in the pub it was the best smartphone I have ever used bar none. I promised myself I'd buy one once I could afford one, but by the time that day rolled around they'd discontinued the thing.
I still really, really miss my little Motorola Milestone too. Touchscreens will just never be as good to type on as a physical keyboard, even when you're only using two thumbs.
[Author here]
> the best smartphone I have ever used bar none
Certainly up there with my Nokia E90 Communicator. That was >< this close to greatness, but was just a bit too limited, in some ways that the Passport fixed.
The Passport's keyboard was, for me, right on the lower size limit of usability. I was slower on it than on Swype but much more accurate, and corrections were much much quicker.
The OS was good, although I had to manually monitor background tasks and kill them occasionally. The warning was when the device got hot enough to feel it on my leg in my trouser pocket, but by then, it had burned 10-20% of its battery on the runaway task.
Its unified inbox was so wonderfully elegant that it makes the best iOS and Android have to offer look like total amateurish junk.
But gradually 3rd party app support disappeared. Facebook Messenger stopped working. The Android version did but couldn't integrate into the inbox.
Then Whatsapp disappeared.
Gradually the comms-centric device stopped communicating with all services I needed.
This is why, incidentally, I want to see all messaging vendors legally compelled to be open to existing open standards and allow connections from 3rd party client apps. Not web apps, proper local clients. Everyone: Facebook, Whatsapp, Signal, Telegram, Zoom, iMessage, Teams, Meet, Skype. Comply or you have two choices: shut it down, or sell it off.
"This is why, incidentally, I want to see all messaging vendors legally compelled to be open to existing open standards and allow connections from 3rd party client apps."
Well that's an interesting request. How do you intend your system to deal with the situation where someone makes a new chat app because they want to offer some feature that's not supported by whatever open standard you've selected? That feature could be a lot of things, from a different format of media to a new encryption strategy. Most of the apps in your list were originally made to add some new feature that previous chat systems lacked. You could deal with a few of these by embedding more and more information in the message, and old clients just dumping unsupported messages out as text. That would work for a few things, although it's not pretty. However, for anything where the architecture is substantially different, for example if they change the routing mechanism to something decentralized or start using asymmetric encryption with user-provided keys, that won't work either. So far, I have opposed similar requests because I don't have a good solution to this problem and I don't want to lose the benefits of new systems. Do you have an alternative?
For the providers designated "gatekeepers" under the EU's Digital Market Act, it's not a request, it's an obligation.
The problems may not be easy to solve, but they have to figure it out somehow.
https://www.theregister.com/2023/03/29/eu_mandated_messaging_interop_paper/
Which, so far, I oppose for the reasons I stated. I have yet to see anyone explain how any of this is done without breaking most or all of the reasons why multiple messaging protocols exist. I thought that Liam, having expressed interest in the concept and having some technical experience, might have an answer to this. So far, if he does, I don't understand it.
The law as it's currently written basically just calls for this to somehow happen and doesn't explain how or give any criteria. As far as I know, nobody is taking steps to make it happen, and there is a distinct chance that they won't be able to manage it while keeping encryption working. I doubt that was the intended goal when the law was drafted, but I also doubt that the theoretical loss of end-to-end encryption will bother those who passed the law very much. It would bother me, which is why I'd like to see a suggestion on how to keep it and the various other advantages or the requirement reversed. I don't have a good solution myself, so I posted in the hope that someone else had thought of one and could convince me.
Interop doesn't mean everything has to support everything else. Just there's a minimum subset everything must support in a clearly defined way. Your new killer app could still add features beyond this.
If they're really so good they become a universal demand, you'd probably be required to include the details in the interop standards. But that's just describing the data, not how your product uses it. Your product still has first-mover advantage.
On the other hand, if the feature is more than niche, but less than universal, it'll still get good traction without needing to open up.
> How do you intend your system to deal with the situation where someone makes a new chat app because they want to offer some feature that's not supported by whatever open standard you've selected?
ISTM that while this is a real issue, it is not beyond the wit of Man.
As a parallel: Thunderbird can talk to Exchange Server, given a suitable connector on the server. I have used this in at least 2 past roles, partly because I detest Outlook, and partly because if one is running Linux, one doesn't have the option of Outlook anyway. (I personally consider the web version beneath contempt.)
While Outlook-to-Outlook users get rich text, in MS TNEF or whatever it's called, and the ability to recall messages and other fripperies I don't want anyway, the point is that T'bird worked well enough at the level I want. I can get mail, send mail, keep mail on the server, manipulate folders, search and sort and filter, access the corporate address book, access the corporate diary, etc.
There are multiple potential protocols. Let us remember that under several of its names, Google Talk used to work over XMPP. So did Facebook Messenger. If it did it before, it can do it again.
A starting point is: I expect the baseline support to be whatever that protocol can handle, and the vendor's implementation should gracefully degrade when a standards-based client from a 3rd party connects.
In a messaging app, I don't want or need animated emoticons, say, to pick one Apple extension I can live without.
What XMPP provides for one-to-one chat works for me. What Matrix provides for many-to-many is also acceptable.
However, if you're not clear, then both projects fail to meet your standard. Exchange is breaking compatibility by not including the rich message whatever it does, and Thunderbird is failing to be compatible by not supporting it. In this case, I think it's more Thunderbird not supporting it than Exchange not sending it, but I don't know for certain. If you ask for interoperability, I see two ways of doing it:
1. Everything must support the protocol of everything, which either means that I cannot introduce new features because it would break compatibility with anyone else or that, if I do introduce new features, everyone must adopt it. It sounds like neither of us want to do this.
2. Everything must support some standard communication system in addition to whatever protocol they were built for. You can do this, but what's the point? Anyone who uses it is presumably using it for its unusual features, which will be the reason it has a protocol other than the standard. If they just wanted another XMPP client, they have a bunch to choose from. We might as well make that standard email and tell every chat system that they'd better bolt on a mail client. Those systems having the feature won't make anything easier for the users.
Liam Proven,
Its unified inbox was so wonderfully elegant that it makes the best iOS and Android have to offer look like total amateurish junk.
Windows Phone got close to what Blackberry could do in terms of the people hub, where you could have all your communications with a contact in one place. It was also very good at allowing you to separate out personal contacts and work ones. From what I've read it wasn't as good as Blackberry, but then I didn't like the rest of the Blackberry OS - or the keyboards.
Didn't the Palm Pre also do similar things?
But sadly they all died, and left us with Apple - who've added more bells and whistles to iOS but barely changed it in a decade. Plus Android, which keeps changing its menus and look, but also doesn't seem to have innovated much in terms of displaying all the information available.
Purely for the nostalgia, I just picked up my Zaurii, pulled down the slider on each and revelled in the feel of the keyboards - the sleek silver of the 5500 and the bold black 6000: so much easier than a touch keyboard and far less likely to just slip from the grasp. A decent single-handed thumb typing experience (and being able to use a stylus, just like the Palm Pilots, made for simple precise pointing as well, but that is another discussion, about the cost of a Wacom-enabled 'phone...)
I hear tales that a modern 'phone can be used with the thumb of the hand holding it, but I have yet to manage that without speaking out loud all the gt£%@4ghy%)'$°] that inevitably results.
[Author here]
> the sleek silver of the 5500
Huh. I didn't expect Zaurus nostalgia.
I had one. (In fact, I had two at one, brief point.) Complete with a wifi CF card.
I really didn't like the device at all. As I recall, the keyboard didn't have a pipe symbol anywhere, which is baffling on a pocket Linux computer.
It was slow, critically short of RAM and nonvolatile space, and had no swap so stuff crashed a lot. I experimented with 3rd party OSes, repartitioning, putting the filesystem on CF cards, anything I could find to make it more usable, but nothing worked well enough to make it anything other than horribly constrained and limited.
I am delighted to learn others did better and liked them. They were clever little devices but not for me.
I admire the work that goes into something like this, but I have to wonder if the work might not be better spent making a different keyboard rather than using a specific model from an old device. I don't imagine that many Fairphone users happen to have that particular Blackberry around, and they're not cheap and plentiful on the second hand markets. This board will, for most users, provide them the ability to connect something they will never have, and that will only get worse if they do extend this to other phones.
Other open hardware projects have built their own keyboards, and I wonder if it might make more sense to try to do that or find a part that's currently in production. The creator of this hardware may be doing it because they do have such a Blackberry available to cannibalize and might not be focused on the ease for others to adopt it, but they've gone to a lot of effort that I'd like to see pay off.
Search for "Blackberry Q10 keyboard" on AliExpress: there's a lot around, either as unused spares or salvaged from e-waste.
Designing something like a keyboard is difficult, and refining it to the point where it is as well-regarded as the Blackberries' is well-nigh impossible. Not to mention MOQs for the specialist parts which are probably in the thousands.
Apropos components, it appears to be only the Hirose connector which has to be sourced and soldered by the purchaser, and it probably wouldn't take many people clubbing together (order of 100?) to get JLCPCB to add it to their list in short order.
And they do have competitors...
More of an issue is the final housing. 3D printing- /particularly/ if it's FDM (Fused Deposition Modelling)- benefits enormously from manual finishing which is not a million miles removed from high-end car bodywork. Filler-sand-repeat several times, then paint: relatively few people have the patience to do a good job of it.
Physical keyboards are definitely nice. I miss my Blackberry Passport, the best phone I've ever had, and Blackberry 10 OS, the best phone OS I've ever used. I also really liked the slideable keyboard of my Blackberry Priv, although Android was too heavy for the CPU so I actually ended up hating that laggy phone. Could type "blind" (under the table) or drunk and never made any typos.
But the Fairphone is already huge (>16 cm tall) - won't this just make it even more enormous?
I had the Sony Ericsson P990i as my first smart phone with a touchscreen and it was pretty decent. used it right up until 2011 after about 4-5yrs of reliable use.
Removable battery, could remove the numpad flip front with ease. Good call quality and a nice clear colour screen.
I actually miss phones that would last for days on a tiny battery and had a proper keyboard... If there was a decent alternative, I'd consider it for my next phone... I've had my Pixel 6 pro for about about 20 months so far and not impressed with the camera at all.
The obvious " slip on " keyboard without electronics but simple contacts with the screen seem to be something to investigate.
Why use electronics at all when a simple passive plastic keyboard can do the job ? ..
simplify the design a notch. There's no need for electronics at all.
Granted different models different screens might require a diff keyboard layout but frankly ,
a 10 cent piece of plastic can be produced for different models and you have your keyboard.
They do the same for protective cases . Why not a KB ?
Just food for thought .
The main issue I can see is that not all on-screen keyboards have precisely the same layout, and shifting to numbers or characters can really change the game. Any subtle update to the keyboard software would potentially change the layout and break interoperability with a dumb slip-on device, as well. At a minimum, you'd want a driver which reads information about the current layout and transmits it to the slip-on keyboard.
The other issue, of course, is that you then have to remove the keyboard from the device when you're no longer using it, although this could be addressed by making it foldable.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
