search

veikman / dactyl-keyboard

Programmatic keyboard CAD
GNU Affero General Public License v3.0
268 stars 30 forks source link

Some future thoughts #16

Open 20lives opened 4 years ago

20lives commented 4 years ago

Hi Viktor You made a great work expanding @adereth and @tshort work and making this project as customizable as possible to the point that any keyboard can be built with it. I think the next step should be declaring this project as such.

After gaining some experience with it I think that "getting started" is really hard. The workflow and syntax aren't intuitive and the docs need expanding, additionally, more examples (like this #15) could really be helpful understanding the basics.

tshort commented 4 years ago

How about making PR's to the intro.md doc? There's already a lot there.

veikman commented 4 years ago

Thank you; I agree that getting started is too hard.

At the moment, my own future plan is based on an orthopaedic brace I made out of scraps of wood for my third full print, replacing the connecting rod it used to have.

Image of the third working DMOTE

The plan looks roughly like this:

  1. Improved REPL support.
  2. New feature: An optional central housing that connects two mirrored “split” parts via screw mounts, enabling massive tenting (hence minimizing unergonomic pronation) and the use of a single microcontroller per keyboard.
  3. Restoring lost features of Tom’s design, including a full-size USB socket, and implementing these in the Dactyl-ManuForm build target of this project until reaching parity with that original.
  4. Prototyping and testing the new stuff, including SLA keycaps over in dmote-keycap.
  5. Beginner-friendly documentation in the form of illustrated step-by-step design guides and a basic physical build and firmware guide. Not sure whether to put these in doc or in a GitHub wiki or on my own page. I’d appreciate input on that.
  6. Release as version 1.0.0.
  7. STLs on Thingiverse.
  8. Petitioning @tshort for an upstream merge of this fork into its parent.
  9. Possibly telling somebody about the project? I am amazed at how many people have found it just through GitHub’s graphs.

... not necessarily in that order.

The far future: Input measurements of your hands, get a recommended personal configuration in a web GUI with the world’s slowest rendered previews. This is a quit-your-day-job scenario and I don’t even have a Patreon.

20lives commented 4 years ago

The thing is that you don't have to do all of this alone, there is a great community willing to take part, and i think that the main obstacle is that the project is a little bit messy and convoluted (legacy reasons :p)

Having #5 higher priority might help with that.

veikman commented 4 years ago

To be sure, I am grateful for all the help I get, and how-to articles should be a relatively easy way for others to contribute. However, there’s always a trade-off. The earlier we write guides, the more maintenance they will require. Multiply by the number of guides.

In the last few releases, the results of running the application with default parameters have varied a great deal, and may continue to vary. The more we invest in the current state of the application, as part of its repo, the greater the risks of ossification and internal contradiction down the line. That is why I imagine a small set of very basic official guides:

I’m thinking that any more advanced how-tos, including your Let’s Split, will work best as blog posts and other articles separate from this code repo, specific to some concrete version of the project, to keep the maintenance burden under control. For example, you will have noticed that the bottom plate on your Let’s Split render does not extend to projections of the screw anchors meant to keep it in place; this is one of the details I aim to fix as part of Dactyl-ManuForm parity, and the fix should properly require an update to any how-to that shows the Let’s Split.

This repo should include (curate) a collection of links to such project-specific guides, but I don’t expect the community to maintain them all in step with the application. The central idea is to make keyboards to fit hands, and there’s a lot of hands in this world.

GabeBolton commented 4 years ago

In my humble opinion including some .stl examples of what the parameters should do would help give new users an idea of what to experiment with first, and an example of what has worked for you.

doordormeta commented 4 years ago

I have completed the keyboard and made few pictures along the 8 month journey as a non-technical guy (anyone else did? Am I your first?). You do not need to have a guide, just a write-up of the journey that will not need to be maintained, only edited before release.

proccy

veikman commented 4 years ago

You are the first that I’m aware of. Nice build! That black looks very smooth. You’ve even got i3 and Cyberpunk 2077 for props. It’s a whole retrofuturist vibe, like the split keyboard that shows up in Blade Runner 2049. I hope the layout works for you.

Progress on documentation thus far: A more extensive guide to running the application, separated from the introduction, and tables of content for the auto-generated documents.

There will be STLs eventually, probably in another repo or on Thingiverse.

doordormeta commented 4 years ago

Thank you! That's Sway (Wayland) + Dvorak I learned in the meantime. I'm Polish so Cyberpunk 2077 is a showoff. I took a year off from work to throw Windows through a window and rework everything from the ground up.

I assume you don't need the "story" of the build, Ill eventually send you my thoughts/hiccups in a PM to consider.

GabeBolton commented 4 years ago
  1. Prototyping and testing the new stuff, including SLA keycaps over in dmote-keycap.

A super helpful add-on could be a thumb trackball and mouse keys. I'm want to start messing around with possibilities as soon as I get my first DMOTE made, or maybe even before.

  1. Beginner-friendly documentation in the form of illustrated step-by-step design guides and a basic physical build and firmware guide. Not sure whether to put these in doc or in a GitHub wiki or on my own page. I’d appreciate input on that.

At the very least in the time being making the link to the page on your site more obvious so folks don't just find it by chance could be great. Also having link straight to the gallery would be great so people can keep looking back to it to remind themselves of the awesomeness that is the end product.

  1. STLs on Thingiverse.

There will be STLs eventually, probably in another repo or on Thingiverse.

In the meantime even hosting some STLs here would be very handy, I really like github's STL viewer.

veikman commented 4 years ago

@Plateaus – I look forward to it! Congratulations on your liberation.

@GabeBolton – I have not considered an actual trackball, but I have looked into trackpoints (no suitable open firmware, hard to source parts?) and rotary encoders (easy to do, less useful). I imagine a trackball is worth a shot, implemented in DMOTE as a special type of key, but I suppose it would act as a separate USB HID? Mouse keys are already in, if you count regular keys sending mouse movements and clicks via QMK.

pel-daniel commented 4 years ago

This looks amazing Viktor. I've been also thinking about adding a trackball to the side of the keyboard, and today I came across this blog post https://www.billiam.org/2019/05/29/sherbet-an-ergonomic-keypad. I will need to give it a try sometime soon.

veikman commented 3 years ago

The planned tutorial for getting started with the application, designing from scratch, is now live here. I would appreciate feedback on it.

laur89 commented 2 years ago

@veikman unsure if it could be of any help, but UHK sells trackpoint add-on modules for their keyboards, and their firmware is open: https://github.com/UltimateHackingKeyboard/firmware