yashsingh1/xdaforums huggingface dataset:
[Project Ara General] ajbiz11:
I'll make a rough Cinema 4D concept of my keyboard module this weekend

Sent from my m7spr
[Project Ara General] rubixcube:
I'm sorry to get this thread up from the grave, but i have read it and here is what i think.

What about a full keyboard in a similar way of the flippypad ? http://38.media.tumblr.com/44dcb993af7413c7b3f0f5bbf88b658f/tumblr_n490sze0Ta1rz9inho1_1280.jpg

I would totally buy something like that !
[Project Ara General] ajbiz11:
Its not compliant to Ara's rules

The module can't extend beyond the bezel

Sent from my m7spr
[Project Ara General] crutchcorn:
Wait a minute, that's not true. They have some leway
[Project Ara General] divie:
This method negates the normal portrait smartphone/touchscreen use of the phone. Since the touchscreen will be accessible only when the phone is opened up, it will always operate in landscape mode.

A slider variant as opposed to a "flipper?" leaves the choice to the user whether to use landscape or portrait mode.

Think about it this way: How would you ever make calls with this thing without looking ridiculous?

Sent from my SM-T320 with Tapatalk 4
[Project Ara General] crutchcorn:
It's not STUCK to your phone. It's ara, you know, modular???
[Project Ara General] divie:
Believe me, I know. And for a gamepad this could probably work. But a keyboard is supposed to stay on your phone always, and I'm not going to take the whole module off everytime I make a call.

Sent from my SM-T320 with Tapatalk 4
[Project Ara General] mystik1:
You and I have the exact same thoughts. I want the option for a top-end hardware, large screen phone with a physical keyboard. It's not that I can't get by with a virtual keyboard in itself. The problem for me is the screen real estate the virtual keyboard takes up. That added with the fact that only some virtual keyboards work through Remote Desktop (where I work extensively) makes the problem even worse. Some web sites are built in such a way that when you have the keyboard showing, you can't even see what you're trying to type. Similar problems when working through Remote Desktop. I couldn't care less if it weighs more or is thicker. I am perfectly fine with that.
[Project Ara General] ajbiz11:
I honestly have no problems with any keyboard using Microsoft's RDP app

Haven't tested Fleksy, though

Sent from my m7spr
[Project Ara General] mystik1:
I will have to give the MS app another try...
[Project Ara General] nxdu:
Here's an interesting look into Jolla's own community-made keyboard prototype:

http://www.jollausers.com/2014/09/2nd-revision-of-qwerty-keyboard-otherhalf-demoed/
[Project Ara General] DragonMama:
I commented on that post about key layout. What the bleep is with all these bleeping bluetooth keyboards that straight stack the keys into columns that make it pretty much certain that you'll hit the wrong letter about 20% of the time? URG! I'm still using a MyTouch 4G Slide (from July 2011) because I can NOT stand typing on a screen and I've got 4 kids making noise in the background (or I'm trying to have a conversation I don't want them to know about hence why it's in TEXT) so speech-to-text is a big stinky fail whale around here. Stagger-stack the keys like they are on a regular keyboard, that's how you keep the errors low - and make the bloody space bar wide enough to recognize it by touch instead of hitting whatever not-as-frequently-used "helpful" key is positioned next to it (I actually popped the bleeping back button off the MyTouch slide out keyboard because I kept hitting it when I went for the period key).

Also, for you designer types, consider taking inspiration for the keyboard expose/hide functionality style from the old Palm OS Sony Clie. The keyboard was connected to a hinge that was on the screen - the screen could hinge open (looked like a huge flip phone) and it could also rotate so that the screen was closed into the keys when not in use or the screen could be rotated out with the keys protected from accidental bumps when using it purely as a touch device or with a stylis (ahh... not having to get finger smudges all over the screen when sketching something reasonably precisely.. those where the days). The camera was on the hinge and rotated, so the lens was protected when not in use and rotated out without being blocked in whatever position the keyboard was in while the camera was being used. NOT suggesting that portrait mode would be good for typing, just pointing out that sliding isn't the only motion option we've got. Think the gamepad module that was linked to earlier, but with a lovely Motorola style keyboard on it and the swivel hinge.

And after all that, PLEASE for the love of all that is good, holy, and maternal, make a water-resistant, drop-resistant case for the bleeping thing that lets the keyboard stay on!!!!

My main MyTouch has gone into bootloops that even updating the recovery and trying different ROMs isn't fixing. I'm going to beg an electrical engineer friend to take a look at it and I'm trying to get my backup (grrrr S-On because I'm too chicken to do the wire trick) running in the meantime and eyeing some replacement ones on eBay.... HOPING that I only have to keep a functioning MyTouch going for another 6 months or so before I can get a happy little Ara.
[Project Ara General] pikmin23:
Anyway wants to pickup this project? It was the most promising alternative to a sliding keyboard: https://www.google.com.sg/url?sa=t&...ABEfw6CUc6TCCX3ZQ&sig2=cDyLtlwp0QB1pTWojavJ2w

Too bad it got canned
[Project Ara General] divie:
No offense, but that thing looks disgusting.

Sent from my SM-T320 with Tapatalk 4
[Project Ara General] pikmin23:
Ouch that hurts :(
[Project Ara General] ajbiz11:
It appears to have been shipped

Is it really dead?

Sent from my m7spr
[Project Ara General] riahc3:
That looks disgusting. That isn't a keyboard, its a keypad.

One of the keys on my Desire Z just fell off :( Im desperate waiting for Jan and HOPE that something with a QWERTY keyboard comes by.
[Project Ara General] qeef:
Just one more question about slider keyboard - would it be hard-connected to display or like middle-module? I guess that the middle-module solution is preferred, but what policy of ara modules says? Is it possible to make a module (slider keyboard) to which other module (display, front camera) is connected?
[Project Ara General] ajbiz11:
The network protocol hasn't exactly been wide spread, but the idea of a middle module will fit the size guidelines

Only concern is if it will actually communicate

But yeah, I picture this looking like an PG Droid with the slim-bar being at the top (camera slot)
[Project Ara General] qeef:
Excuse me, it's quite a while I read the MDK, so maybe something wouldn't be exactly written..

In fact, I am not concerned about size but about the fact, that google use some kind of fixation for modules (like magnets, but different for front display modules). And making some kind of middle-module means that this technology have to be duplicated in middle-module to ensure fixation of display, front camera.

About communication of modules - my guess is that one connector for display will be enough. But it's really just a guess.
[Project Ara General] crutchcorn:
My best guess is that it'll have to be the whole display module. We know that display modules will allow there to be keyboards but I don't think google will allow there to be another layer
[Project Ara General] ajbiz11:
By my memory, the prototype used electro-permanent magnets

Basically, they're 1-3 Nutons when off, iirc, but the have a pulling force of hundreds of neutons when in the on position, yet require only a pulse of electricity to switch modes

Not sure if the display used the same tech though
[Project Ara General] crutchcorn:
Fairly sure display modules use same tech
[Project Ara General] xysawq:
Flipped keyboard

I saw a picture of a gamepad online (see attached) and wondered why this would not work with a keyboard too.

Maybe also the keyboard could inherit a much larger battery or some additional connectors like HDMI so you can surf the net on you TV with a keyboard.

I haven't read the MDK yet but I am very excited about the phone, the possibilities and the huge amount of creativity to see in near future.
[Project Ara General] Joe_PDA:
I think you guys are approaching this wrong. Forget Googles, "rules" This is a concept that is supposed to allow us to build a communications device spec'd the way we want.

Since so many people want a physical keyboard, why not figure out how to design it and make it work with Google's hardware and software. The chassis is 2 sided. Most of the

electronic components, including those to drive the keyboard would be located on the back (see attached graphic). On the front of the chassis would attach a screen/keyboard module.

I photographed my old HTC Touch Pro to give you a rough idea. By locating the electronics on the back of the chassis, in one of the component slots, the keyboard itself is quite thin (about 2mm).

The screen and all the slider components are attached to that. The slider components are all in the part with the actual display.

Since the front has 4 connectors (13, 14, 15 & 16), the keyboard and screen could connect to one or two of those.

The only problem I can see, is that the keyboard/screen module, which is a bit heavy, would need a secure way to attach to the chassis. I think it could be made to slide in between the

top and bottom endo ribs. It just may need some other way to lock since the slider is a moving part.

This entire module would only add about 7 mm to 8mm height. I can live with that for a device spec'd the way I need it and changeable as the situation changes.
[Project Ara General] xysawq:
So this is nearly the same idea dsfdfsdfs hat in post #5.

To sum it up i would say there are 2 solutions.

One is the slider and the second is the hinged one.

The slider module would have tp go between endo and display, so no module gets covered (other modules might also be thicker, like cameras and therefore this would not work) and the hinged module would have to be connected to the back of the endo, where the keyboard would flap over the display.

I myself would prefere the slider to be honest and I would design it to copy the front endo connectors, so you can place the display, speaker/front camera/sensor on top of it. the slider mechanism itself is not that huge and the module itself would hold tight due to the magnets.

Thet would not add 8-9mm but maybe just 2-3mm.

The hinged solution would be the same plus add a hinge on the side and might be less stable since you hold it on the keyboard module, but all the weight is in the top.
[Project Ara General] riahc3:
The "Nintendo DS" idea would be difficult to implement.

Basically you would have 3 positions

1: Closed (the display facing the keyboard). Non operative.

2: Opened with the display tilted and the keyboard open facing up (ala Nokia 9500 Communicator). Both touchscreen and keyboard would be operative.

3: Fully open with the display facing south and the keyboard facing north. For practical reasons, in this mode, the touchscreen would be operative but the keyboard would not.

Designing something like that would be very difficult and you all saw how the Nintendo DS turned out.

Right now, the only thing possible (and Google is thinking about) is a BlackBerry keyboard. Take it or leave it. Its the best we are going to get...
[Project Ara General] Joe_PDA:
The slider idea is the best and most practical. Now we just have to determine how best to implement it.

There are options to add modules to the front of the device, so we need to work from there.

I see two options. One is that the keyboard and screen are one unit. this way, all the electronics fit together.

The problem with this idea is then we cannot swap screens if better tech is developed.

The other option is to make the keyboard and slider mechanism as one module. This would connect to the

front of the device as I and dsfdfsdfs had suggested. This would still connect to 13, 14, 15 or 16, as per my last post.

The sliding mechanism would need its own endo ribs and connector inputs, so any ara screen module could be attached.

The design is quite simple. The whole mechanism with screen will add maybe 8mm, to the total thickness, which I think

we could all live with, to gain the functionality of the slider keyboard.

The only downside about this design is attaching the keyboard/slider mechanism to the ara chassis may need a semi

permanent fastener, since this is a moving part. This could easily be accomplished without changing the ara chassis.

anyone up for making this happen?

---------- Post added at 04:50 PM ---------- Previous post was at 04:35 PM ----------

I think it must be made as a middle module. This way, new screens could be swapped as they improve.

Or, if I know I will not need a high resolution display, but need max battery life for a trip, I could swap out

my super super 4d oled 1440p display, for something a little more battery friendly.
[Project Ara General] sammi123:
Sliding keyboard may not be feasible

Just read another project ara forum (projectaratalk), one people mentioned the white box theory. I start to concern whether the skeleton can handle the mechanical movement of a sliding keyboard.
[Project Ara General] crutchcorn:
That's a good point, what's the theory say?

---------- Post added at 05:18 AM ---------- Previous post was at 05:16 AM ----------

But then we'd need a controller to handle the screen data and pass it through to the skeleton. Basically combining the data.
[Project Ara General] ajbiz11:
My understanding of the Ara module network is that it is exactly that. Were looking at a network

.

I am considering applying for a Spiral 2 Dev board and I have access to a 3D printer and someone who is very very good with hardware.

With the help of you all, I would like to try and make this a reality.

Edit: I should clarify

I'm very much an Android software developer, but I understand how hardware interfaces with normal systems.

I'm not amazing with IC's but my best friend is.

As a team, and with community help and input, I think this could be possible

The main thing I'm not sure on is the magnets

For one, I don't understand how the screen will be told to disconnect, since you need the app to disable the magnets, yet the display isn't disabled unless the phone is off

My thoughts on that are to use a sensor to detect when the display would be off and mimic the system in the display shelf (disconnecting the keyboard would result in the display being disconnected anyways, so the phone would need to be off)
[Project Ara General] trippymanni:
I was thinking of a possible swivel screen. With shells and modules it seems pretty doable. Be great for photography and watching movies and what not.
[Project Ara General] ajbiz11:
Well I applied for a Spiral2

Time to look at the updated MDK and bit bang old keyboards

If anyone has a T-Mobile G1 or any Droid phone with a keyboard and are willing to part with it, please let me know

I currently only have a Palm Treo Pro to get a current keyboard from

A nice thought, Ara seems to be able to interface modules as USB
[Project Ara General] crutchcorn:
I am becoming a hardware developer, and understand the basics of such. I also am a developer so any way I can help let me know.

---------- Post added at 08:35 AM ---------- Previous post was at 08:29 AM ----------

If Ara can interface as USB, then would that allow us to easier have the display's data carried over better?
[Project Ara General] ajbiz11:
I will most likely be posting here a lot if anything happens

As for the USB and Rs232 support, yes it will make passing the display much easier

Since they are different protocols, and maybe even over different pins (I need to check) then bussing the right information just got a whole lot easier
[Project Ara General] garva1:
Awesome concept.
[Project Ara General] crutchcorn:
Cool stuff. I figured as much, the only issue is if they share PINs. I haven't read too much on the MDK yet. Just a little. However I want to double check that the PINs don't overlap. The biggest thing is that we should try to optimize using the lease amount of PINs possible so that the screen can utilize whatever it wants (front speakers, camera etc).... Then again.... We now have another issue. Do we try to support that or not? Because the spines have two parts on the front; a top smaller part and a larger part below right? Or maybe I'm mistaken again.... Just away from my computer and it's 3am so if I seem stupid I'm sorry; I just draw all my smarts from my PC. [emoji14]
[Project Ara General] qwerty_man:
I'm an electronics hardware designer by trade with some skills in 3D design and programming. I just stumbled upon this by googling qwerty-keyboards and I think the idea is great, but the design approach discussed here isn't really that great (placing the keyboard + mechanism in the screen-slot). The reason I think it isn't a great approach is because it's unnecessarily complicated and expensive to create slide-out keyboards for all screen-sizes. On page 23 of the MDK there are more than 10 examples of different screen sizes, supported by the ARA skeleton standard. That means creating > 10 different keyboard modules with > 10 different screen slots?

After a quick look at the ARA MDK, the most logical thing in my opinion would be to hook the QWERTY-keyboard into the camera slot ("Interface block unique ID 1" in the MDK docs) and use whatever communication protocol(s) available there for both the camera datacom and keyboard datacom. The keyboard slideout/flipout mechanism would then need some extra mechanical fixing (not that hard to do for any mechanical engineer) to the ARA endoskeleton. That way the keyboard when "folded up" lays on top of the back of the smartphone and when "folded out" all the ARA blocks on the back can be accessed without any problem. The camera block with the actual camera on it, could just be slid into the back of the QWERTY-keyboard module. All you'd have to do to make any camera module work, is just "copy" the ARA camera slot design (both mechanical and electronic) into the back of the QWERTY-keyboard design. Not a very hard thing to do since the ARA cam-slot design is already there. Electronically you could just trace all CSI-3 protocol camera pins straight through the keyboard module onto the ARA-camera slot CSI-3 protocol pins and use a separate protocol for your keyboard doings. This design would mean all camera modules that are slid into the keyboard module would work with ARA without any hardware/software modifications at all (since the electrical connection for the cam is just the same as if it would be directly on the ARA).

The user of this configuration would get the same user-experience as he'd get with the now outdated (but once very popular) HTC desire Z2 type of smartphone with QWERTY-flip-out keyboard option.
[Project Ara General] divie:
I wonder if that would be strong enough to hold. This method puts a lot of stress on the magnets. And if while typing the magnet fails to hold, your whole exoskeleton with all the modules falls on the ground.

I think for a real proper qwerty keyboard construction we'll need a custom exoskeleton. Or at least, half of it, IE an extension of the exoskeleton with the same module slots.

Sent from my SM-T320 with Tapatalk 4
[Project Ara General] qwerty_man:
I agree that it would most likely not be able to hold by just the magnet. Having said that it can't be that hard to create a mechanism which somehow that "clicks around" the exoskeleton to actually mechanically hold the keyboard and it's mechanism in place.

I'm convinced this is an issue that can be solved relatively easily at design-time by any skilled mechanical engineer.
[Project Ara General] divie:
That means the result would look something like this

with the only difference that it isn't connected by bluetooth but through the module. I think, just like that particular keyboard case, the whole deal would be unmanagably thick. In reality such a keyboard case feels like two phones sliding on top of eachother.

I'm starting to think the only way to properly implement a sliding hardware keyboard to project ara is underneath the top modules and pass the signal or something, or at least under the screen. And I'm not sure the latter would look pleasing...

Anyway, just my constructive criticism here, by all means no offense.

Verstuurd vanaf mijn PHOTON Q met Tapatalk 4
[Project Ara General] qwerty_man:
That's exactly what I meant indeed, except I don't agree with the "unmanagably thick" part. Yes it will be thicker, yes it may feel like 2 smartphones on top of each other, but that's what all QWERTY smartphones always felt like to me and it didn't really ever bother me enough to no want a QWERTY keyboard :P I think true QWERTY lovers wouldn't really mind this limitation all that much.

Huge advantages of not doing this over bluetooth:

-- Saving battery power. It's really overkill to waste battery power for a relatively power hungry bluetooth connection that is only used for keyboard functionality.

-- More reliable and userfriendly when not using a bluetooth connection, but instead using a wired or inductive direct ARA connection (no setup, no bull****).
[Project Ara General] ajbiz11:
[MENTION=6392785]qwerty_man[/MENTION]

While I understand the concern of making multiple modules for multiple screen sizes, you also talk about clipping to the border of the device...wouldn't that mean the dimensions would have to change anyways?

---------- Post added at 08:41 PM ---------- Previous post was at 08:40 PM ----------

Apparently I can't spell your name so I'm quoting you now
[Project Ara General] qwerty_man:
If you'd want to support all 3 ARA sizes you'd need 2 or 3 different keyboard (frame/mechanism) dimensions.

This is true for all other types of ARA modules too!

That is, if you do it by putting the keyboard on the back hooking into the camera slot. If you'd want to build the keyboard onto the front side of the ARA (behind the screen), it would mean at least 10 different mechanism sizes to support all screen sizes and ARA size variations (see page 23 of MDK).

Actually I think this is inherently a huge limitation of ARA as it is defined now. To me ARA is all about standardization of sizes and protocols so that it becomes attractive to build modules for it (at least at first). But they start out with 3 different "standard sizes" all at once. This kind of defeats the purpose of ARA IMO. For example: if you'd want to make a camera module that supports all ARA sizes, you'd need to make 2 different modules: a small 1x1 module for the small and medium ARA sizes and a 1x2 module for the larger size ARA. :eek: :eek:

This holds true for more or less all modules as far as I can judge from the MDK.
[Project Ara General] pelago:
Hello. As a QWERTY-slider phone user for many years with different models (most recently, Sony Xperia Pro), I am very interested in this project.

I for one am not worried about the overall device being thicker than a normal phone. However, one thing I have noticed about phones that have been designed with sliding keyboards, compared to aftermarket Bluetooth addon slider keyboards that have been made for iPhones and that Samsung pictured earlier, is the difference of weighting between the keyboard section and the screen section.

With phones that were designed with sliding keyboards from the beginning, most of the weight (the battery and most of the electronics) is in the keyboard section, with the screen section being much thinner and lighter. With aftermarket Bluetooth addon slider keyboards, the opposite is true, and this makes the device harder to use, as the weight on the screen tips the device away from the user.

I am by no means an expert on ARA or the MDK, but if whatever design that is come up with could accommodate having the keyboard in the same section as the battery and most of the electronics, with just a thinner/lighter screen in the other section, I think that would be a great improvement in ergonomics.