# keyboard A keyboard is a physical or virtual input device used for text entry and interaction with computer systems. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## I had two weeks, an 8-foot keyboard, and a Wordle Workflow DevFeed: [I had two weeks, an 8-foot keyboard, and a Wordle Workflow]() Original publisher: [Read original article]() Author: Shy Ruparel Published: 2026-07-21T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [Development](), [keyboard](), [Figma]() Tags: [conference](), [figma](), [game](), [keyboard](), [temporal-voices](), [usb]() ### AI overview Temporal describes building and presenting a Wordle clone driven by Temporal Workflows, using an 8-foot USB-C keyboard and holographic fans to demonstrate durable execution at AI Engineer World's Fair. ### Source excerpt A Wordle clone, an 8-foot keyboard, and a holographic fan display made Temporal's Durable Execution visible at AI Engineer World's Fair. ## How Temporal's Senior Developer Advocate Built 2,000 Interactive Badges for Replay DevFeed: [How Temporal's Senior Developer Advocate Built 2,000 Interactive Badges for Replay]() Original publisher: [Read original article]() Author: Shy Ruparel Published: 2026-05-20T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [Hardware](), [developer-relations](), [keyboard](), [screen](), [Job]() Tags: [community](), [conference](), [developer](), [electronic](), [hardware](), [interactive](), [manufacturing](), [project](), [temporal-voices]() ### AI overview Temporal Senior Developer Advocate Shy Ruparel describes the design and manufacturing process behind 2,000 interactive electronic badges made for the Replay developer conference, including the project's hardware concepts and production challenges. ### Source excerpt Temporal's Senior Developer Advocate, Shy Ruparel, built 2,000 interactive electronic badges for Replay. Here's how he pulled it off. ## More Accessible Focus Indicators with Compose DevFeed: [More Accessible Focus Indicators with Compose]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2026-04-30T07:11:56.799000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Jetpack Compose](), [Accessibility](), [Android](), [Web Content Accessibility Guidelines](), [keyboard]() Tags: [accessibility](), [accessible](), [android](), [compose](), [focus](), [jetpack-compose](), [keyboard](), [web-content-accessibility-guidelines]() ### AI overview A tutorial on creating more visible keyboard focus indicators in Jetpack Compose. It explains relevant WCAG Focus Appearance requirements, notes that Android's default ripple may be insufficiently visible, and introduces the Indication API for drawing custom indicators such as an underline on focused interactive components. ### Source excerpt Last summer, I wrote a blog post about focus management with Compose. Ever since, I've had drafts of this post, but I didn't get to finalize it until now. The blog post is available in: It's All About (Accessibility) Focus And Compose. So, in this blog post, we're talking about focus indicators and how to make them more accessible with Compose. But let's first talk about focus indicators in general. Focus Indicators Focus indicators are, as the name suggests, indicators that show where keyboard focus currently is in the UI. They need to be visible so that keyboard and keyboard-emulating device users can navigate around the app effortlessly. An important thing to note is that the focus indicator I'm talking about here is not for the screen reader (e.g., TalkBack) focus. That is handled on the system level. Web Content Accessibility Guidelines (the standard behind accessibility legislation and used with apps as well, despite the name) has some requirements for accessible focus indicators. Per SC 2.4.13 Focus Appearance, the focus indicator needs to be either User agent's (Android system) default styles At least 2 pixels thick and has a contrast ratio of at least 3:1 between the same pixels of focused and unfocused states. Android's default focus indicator is the ripple, which isn't very visible. Technically, it would pass, but if you want to make the application accessible, you'll need to improve the visibility of the focus indicator. Let's next discuss one way to build more visible (and thus, more accessible) focus indicators with Compose. Building More Accessible Focus Indicators with Compose There are several ways of creating the focus indicators. You can, for example, add a border based on the focused state, as Appt.org suggests in their code snippets: Accessibility focus indicator in Jetpack Compose, but if you want anything more complex, you'll want to turn to Indication API. Indication API with a DrawModifierNode can be used to draw complex focus indicators. In ## Adding Navigation support to Large Content Viewer with Compose DevFeed: [Adding Navigation support to Large Content Viewer with Compose]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2026-02-28T04:26:46.364000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Jetpack Compose](), [navigation](), [Compose](), [keyboard](), [screen](), [Code]() Tags: [code](), [compose](), [keyboard](), [navigation](), [screen](), [test]() ### AI overview This tutorial explains how to add keyboard and assistive-technology navigation to a large content viewer built with Jetpack Compose. It presents an approach using focus handling to show item previews, covers keyboard and screen reader navigation, and discusses voice access support. The author notes that the example is a demo and should be tested with users of assistive technologies before production release. ### Source excerpt In my previous blog post, Beyond Font Scaling: Large Content Viewer with Compose, I explained how to build a large content viewer from iOS using Jetpack Compose. The implementation did not include support for keyboard or other assistive tech navigation, so this blog post tackles those topics. A disclaimer: The way I'm presenting the support for assistive tech navigation in this blog post is one approach, and my goal is to provide examples and context, but as always, this is a demo project. In your production app, things might get a bit more complicated, and you might need to handle more variables. So always remember to test the solution, ideally with your users who use assistive technologies. And I hope it goes without saying: Before releasing to production. In this blog post, I'm presenting code for keyboard and screen reader navigation, then sharing some considerations for voice access support. The code relies heavily on the code presented in the previous blog post, so if you have questions about it, please check that post. A link for the full code is also provided at the end of the blog post. Keyboard Navigation Support The pointer input implementation presented in the previous blog post relies on long-press, but keyboard navigation doesn't support that kind of interaction, so we need another tactic to display the item preview. With a keyboard, focusing on an item is a natural choice, so we're going to use that. The idea is that when a user who navigates with a keyboard or a keyboard-emulating device focuses on a bottom bar item for the same duration as a long press, we will show the item preview. We can do this with the following code: NavigationBarItem( modifier = Modifier .onFocusChanged { if (it.isFocused) { scope.launch { delay( viewConfiguration.longPressTimeoutMillis ) previewedItem = item } } else { previewedItem = null } }, ... } We use the onFocusChanged-modifier. Its state indicates whether the current element is focused via it.isFocused. If it is, we ## Creating a Keyboard Shortcut Hook in React (Deep Dive) DevFeed: [Creating a Keyboard Shortcut Hook in React (Deep Dive)]() Original publisher: [Read original article]() Author: hello@taniarascia.com Published: 2024-10-19T00:00:00Z Content type: tutorial Language: en Sources: [Tania Rascia]() Topics: [React](), [keyboard](), [Code](), [App](), [Front end]() Tags: [caching](), [code](), [debugging](), [front-end](), [function](), [javascript](), [keyboard-shortcuts](), [react](), [shortcuts]() ### AI overview A tutorial on creating a custom React hook for keyboard shortcuts. It covers single keys, modifier combinations, key sequences, event-handler caching, stale state, and preventing shortcuts while typing. ### Source excerpt Recently I needed to add some keyboard shortcuts to an app I was working on. I wrote up some example code and decided to write this article... ## Detect Caps Lock with JavaScript DevFeed: [Detect Caps Lock with JavaScript]() Original publisher: [Read original article]() Author: David Walsh Published: 2024-02-06T10:33:10Z Content type: tutorial Language: en Sources: [David Walsh]() Topics: [JavaScript](), [passwords](), [keyboard](), [Users]() Tags: [javascript](), [keyboard](), [password](), [users]() ### AI overview A tutorial explaining how to detect whether Caps Lock is enabled during keyboard events with JavaScript, helping developers warn users when entering passwords. ### Source excerpt Anyone is capable of having their caps lock key on at any given time without realizing so. Users can easily spot unwanted caps lock when typing in most inputs, but when using a password input, the problem isn't so obvious. That leads to the user's password being incorrect, which is an annoyance. Ideally developers could [...] The post Detect Caps Lock with JavaScript appeared first on David Walsh Blog. ## Optimizing your workflow does matter in the long run DevFeed: [Optimizing your workflow does matter in the long run]() Original publisher: [Read original article]() Published: 2023-11-05T00:00:00Z Content type: opinion Language: en Sources: [Arkadiusz Chmura]() Topics: [Programming](), [keyboard](), [Learning]() Tags: [context](), [keyboard-shortcuts](), [optimizing](), [programming]() ### AI overview The article argues that tailoring a programming workflow, improving typing speed, and learning editor keyboard shortcuts can reduce context switching and wasted effort. It uses the author's marathon experience to illustrate how attention to small details and strategy can improve performance. ### Source excerpt Having your environment tailored to you and the way you work can save you from context switching, losing focus, reaching for your mouse, or simply wasting time. ## Switching between apps using shortcuts on macOS DevFeed: [Switching between apps using shortcuts on macOS]() Original publisher: [Read original article]() Published: 2023-08-22T00:00:00Z Content type: tutorial Language: en Sources: [Arkadiusz Chmura]() Topics: [macOS](), [App](), [keyboard]() Tags: [keyboard](), [macos](), [shortcuts](), [spotlight](), [switching]() ### AI overview A developer explains how to switch between frequently used apps on macOS with custom keyboard shortcuts. The approach remaps the right Command key as a Hyper key using Karabiner and assigns shortcuts in Raycast, with BetterTouchTool offered as an alternative. ### Source excerpt This is one of the most common activities when working on a computer. To make it as seamless as possible, I assigned a custom shortcut for every app I commonly use. ## More Accessible Graphs with Jetpack Compose Part 2: Adding Keyboard Interaction DevFeed: [More Accessible Graphs with Jetpack Compose Part 2: Adding Keyboard Interaction]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-06-11T04:27:33.850000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Jetpack Compose](), [Graphs](), [keyboard]() Tags: [accessibility](), [accessible](), [graph](), [graphs](), [jetpack-compose](), [keyboard]() ### AI overview This tutorial explains how to improve keyboard access for graphs built with Jetpack Compose. It describes the limitation that content descriptions are unavailable to keyboard-only users and introduces changing the highlighted x-axis position so users can inspect graph values. The author also notes that switch access is not covered because it did not work and required further research. ### Source excerpt Welcome to the second episode of "More Accessible Graphs with Jetpack Compose" - in this blog post, we'll continue from where we left off in the first one. We will look at improving the (physical) keyboard access for graphs in Jetpack Compose. Link to the first part: More Accessible Graphs with Jetpack Compose Part 1: Adding Content Description At the end of the blog post, I mentioned that the second part would be about keyboard and switch access. After testing my code for the blog post, I realized that the switch access part didn't work. After some deep-diving into documentation, I admitted I wouldn't add it to this post as it would require a lot of research. So there likely will be at least four parts in this "More Accessible Graphs with Jetpack Compose"-blog post series. In the first blog post, we added a Higlighter-component, an overlay on top of the line graph I had built. Then we made it focusable and added a content description for accessibility services. After these changes, a keyboard user can already focus on the different parts of the graph, but there's one problem: The graph legend is not visible. And you may now wonder if it is really a problem - we added the content description, right? The content description is unavailable if you only use a keyboard. If a person, who can see and uses a hardware device for navigation, navigates with the graph in the current state, they probably get frustrated because this is what they would get: They can see that the focus changes but can't see the individual values. If I encountered something like this, I would think there is a bug in the app. Adding Keyboard Interaction Users can already focus on each section, so we no longer need to worry about that. But we'll need a way to change the currently focused position on the x-axis - like if a user was moving their finger on the graph. The highlightedX-parameter is the one that controls the currently highlighted position on the x-axis. We'll need to add a way to change it ## My Advice to a Developer New to Accessibility DevFeed: [My Advice to a Developer New to Accessibility]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2023-01-03T08:57:33.125000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Web Development](), [HTML](), [keyboard](), [markup]() Tags: [accessibility](), [accessible](), [advice](), [developer](), [development](), [element](), [elements](), [focus](), [html](), [html-elements](), [input](), [interaction](), [interactive](), [keyboard](), [learning](), [markup]() ### AI overview This beginner-oriented accessibility article recommends focusing on progress rather than perfection and introduces semantic HTML, keyboard navigation, and listening to people with disabilities. It explains that semantic elements communicate meaning to browsers and developers and support appropriate interaction, while a div styled as a button may work only for mouse users and may not be focusable or keyboard-accessible. ### Source excerpt Learning about accessibility for the first time can feel overwhelming. You start reading, and at some point, it hits you: There is so much to learn! And if you're like me and feel that it's your responsibility to make the things you create accessible, that might even make you feel anxious. And yes, there is a lot to learn regarding accessibility. But you don't need to know everything at once. As Meryl Evans reminds us in her tweet (and a blog post the tweet links to), it's about progress over perfection: https://twitter.com/merylkevans/status/1547635550466674692 So, here are some things I wish I had known when I first started learning accessibility. Heck, I wish I had known these things when I started learning web development! I'll share semantic HTML, keyboard navigation, and listening to people with disabilities. Learn Semantic HTML and Use It So, first thing: Learn semantic HTML. But what does it mean? Semantic HTML, or semantic markup, describes its meaning to the browser and developer in a human- and machine-readable way. So, with semantic elements, a human will know what the HTML element is about, and the browser knows what it should render and how it should behave when a user interacts with it. Here's an example: That button uses a semantic button-element. When it does so, the browser knows what it should do when the user either clicks or activates it with a keyboard or other input device. Here's an example of a non-semantic "button":
I look like a button
So, this "button" made out of div looks like a button and even has the onClick-handler. So, wouldn't a human recognize it as a button? Well, yes and no. It depends on the human. You see, this "button" works only for mouse users. As div is not an interactive element by nature, it doesn't handle interaction the same way as, for example, a button-element. When using a semantic button-element, that onClick-event pro ## Don't Develop Just for Yourself - A Developer's Checklist to Accessibility DevFeed: [Don't Develop Just for Yourself - A Developer's Checklist to Accessibility]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2023-01-03T08:57:24.089000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [keyboard](), [Usability](), [alt text](), [aria](), [ui]() Tags: [accessibility](), [alt-text](), [aria](), [authoring](), [automated](), [blog-post](), [developer](), [keyboard](), [testing](), [usability](), [web](), [website]() ### AI overview A beginner-oriented accessibility checklist for developers. It recommends manually testing keyboard navigation, focus visibility, and other website interactions after automated testing, while noting that the process does not guarantee full accessibility. ### Source excerpt We, as developers, tend to develop sites unconsciously for people like ourselves. If we don't actively pay attention, the sites are often accessible only for certain types of people: Sighted mouse-users, who have good fine motor skills and are good at using computers. It leads to moments where no one who navigates the web with only a keyboard (or keyboard simulating device) can access and interact with the site. It is a pretty big group of people! We have a responsibility to make sites that work for all of our users. In some cases, it is required by law, but it is not the only reason we should care. This blog post is aimed for those at the beginning of their accessibility journey. You might know some things, like "always provide an alt-text for an image," but are unsure what to write there. Or you don't have any idea how to know if your site is accessible at all. Following this blog post won't make your site 100% accessible! The goal of this post is to provide some information about some things to check manually after using some automated testing. Keyboard Navigation First of all, abandon your mouse for a second. Don't use it. Try to navigate through the website using only the keyboard. Try to complete every task user needs to be able to complete on the website. Can you do it? Can you see where you are at the moment? Is the focus indicator (yes, that thing many designers and developers like to remove) visible enough? If you can't use the whole website with only a keyboard, that is an accessibility and usability problem. However, one thing to note here is that keyboard interaction is not necessarily accomplished with just tab and enter, as it has been at some point. The general pattern goes, as WAI-ARIA Authoring Practices state: A primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include mult ## Joining the split keyboards club: a Moonlander story DevFeed: [Joining the split keyboards club: a Moonlander story]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2022-05-07T00:00:00Z Content type: opinion Language: en Sources: [Carlos Becker]() Topics: [keyboard](), [Hardware]() Tags: [experience](), [hardware](), [keyboard](), [story]() ### AI overview A personal account of adopting the ZSA Moonlander split keyboard after standard keyboards caused uncomfortable arm and wrist positioning. The author describes the motivation for choosing a split keyboard and the challenge of relearning to type. ### Source excerpt This post will describe my experience with a couple of firsts: ## Happy New Year, the keyboard and cases are here! DevFeed: [Happy New Year, the keyboard and cases are here!]() Original publisher: [Read original article]() Published: 2021-12-31T00:00:00Z Content type: release Language: en Sources: [Community blog on PINE64]() Topics: [Pinephone-Pro](), [Pinephone](), [keyboard]() Tags: [battery](), [camera](), [firmware](), [keyboard](), [peripheral](), [pinephone](), [pinephone-pro](), [screen](), [speaker](), [torch](), [usb](), [wireless]() ### AI overview Pine64 announces that the PinePhone and PinePhone Pro keyboard case, along with add-on cases, are available in the Pine Store. The keyboard case features a 180-degree hinge, rearrangeable keycaps, open firmware, a 6000mAh battery, and USB-C peripheral support. ### Source excerpt The PinePhone & PinePhone Pro keyboard case and add-on cases are now available in the Pine Store! Go to store About the keyboard case The keyboard case works with both the PinePhone and PinePhone Pro and features a clam-shell design. It uses pogo pins located on the phone's midsection and attaches by replacing the default back cover. When folded, the phone's screen and the keyboard rest securely against each other. The hinge features a 180° design, which not only allows for two-hand typing on a surface but also for comfortable thumb-typing when fully extended. The etched keycaps can be easily relocated for alternate layouts such as AZERTY or QWERTZ. The keyboard case runs an open firmware, which means that anyone with the know-how can alter existing functions or add new ones. The bottom (keyboard) and top (phone) sections of the assembly are well-balanced thanks to the large, 6000mAh, internal battery capable of charging the PinePhone (Pro) during operation. The internal battery effectively triples the phone's battery life. The internal keyboard battery can be manually toggled on/off and the keyboard's battery charge level can be read in the supported OSes; the keyboard remains functional with the battery fully depleted. You do not lose access to the PinePhone (Pro)'s USB-C port, speaker, microphone, or any external features, such as volume and lock buttons, with the keyboard attached. There is also a cut-out for the camera, torch, and headphone jack. The USB-C port on the keyboard is capable of powering both the keyboard and PinePhone (Pro) simultaneously. This means that you can plug in a USB mouse, a USB-C dongle, or some other peripheral while the phone and keyboard's internal battery charge. Please keep in mind that the keyboard case transforms the PinePhone (Pro) into a PDA, which means that taking calls will likely prove awkward without a wired or wireless headset connected. More information To learn more about the keyboard and its journey please read: Februa ## MacBook Pro 14 - a quick review DevFeed: [MacBook Pro 14 - a quick review]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2021-12-22T00:00:00Z Content type: opinion Language: en Sources: [Carlos Becker]() Topics: [macOS](), [App](), [GUI](), [Processes](), [screen](), [keyboard]() Tags: [apple](), [apple-m1](), [apps](), [battery](), [discord](), [keyboard](), [mac](), [macos](), [magsafe](), [memory](), [processes](), [review](), [rosetta](), [screen](), [usb]() ### AI overview A personal quick review of the 14-inch MacBook Pro with an Apple M1 Pro SoC, covering Rosetta 2 compatibility, Activity Monitor behavior, the notch, display, battery life, MagSafe charging, and the keyboard. ### Source excerpt I got a MacBook Pro 14" with an Apple M1 Pro SoC, 16GB of memory and 500GB of disk a couple of weeks ago, and wanted to write my impressions about it, since a lot of people ask. ## Invitation to Play Along DevFeed: [Invitation to Play Along]() Original publisher: [Read original article]() Published: 2020-07-29T00:00:00Z Content type: opinion Language: en Sources: [Community blog on PINE64]() Topics: [Pinephone](), [Hardware](), [keyboard](), [interface]() Tags: [game](), [hardware](), [keyboard](), [pine64](), [pinephone](), [requirements](), [usb]() ### AI overview Pine64 invites the community to design add-on hardware for the PinePhone, focusing on a Nokia N900-style slide-out keyboard and a gamepad. The keyboard has defined mechanical and electrical requirements, while the gamepad remains at an earlier exploratory stage. ### Source excerpt Image from: Дмитрий Куртуков - Keyboard for PinePhone We are currently in talks with a number of hardware vendors regarding a Nokia N900-style, slide-out-design keyboard for the PinePhone. They'll have to produce mock-ups or prototypes for us to consider in the next few weeks. The requirements specify that the new device needs to: Interface with the PinePhone's rear pogo pin expansion connector Fit the PinePhone's form factor Seamlessly replace the current back cover and snap onto the phone Be similar, mechanically and functionally, to the Nokia N900 keyboard We are simultaneously also exploring a gamepad for the PinePhone. The criteria we're seeking in a gamepad are much vaguer than those of the keyboard: The gamepad must use the PinePhone's pogo pins (at least for power) It must attach mechanically to the phone. Preferably in an elegant way - velcro or adhesive are not an option. This add-on project is at an earlier exploratory stage than the keyboard, and therefore there is also some leeway regarding the general direction and shape it can take. Now, we'd like to invite you to play along. While we're waiting to see what the commissioned vendors will come up with, we'd also like to give you a chance to go at it. For the keyboard, we have settled on a 5-row key-arrangement design - a STP of the layout can be downloaded here. If you'll have a go at creating a keyboard then do keep in mind the general guiding points outlined above, but at the same time do not take them as commandments carved in stone. I guess what I am trying to say is - don't let the criteria restrict your creative vision. Suggested keyboard layout (filled in by hand) Regarding the game controller; since we're at a very early exploratory stage, you're welcome to explore a variety of approaches to creating such an add-on for the PinePhone. In other words, 'anything goes' as far as the controller's design is concerned. Functionality wise, the controller will have to be powered via the pogo pins but I t ## Implementing mouse pointer interactions on iPad DevFeed: [Implementing mouse pointer interactions on iPad]() Original publisher: [Read original article]() Published: 2020-03-24T21:00:00Z Content type: tutorial Language: en Sources: [Rambo Codes]() Topics: [iOS](), [ui](), [coding](), [GUI](), [Xcode](), [keyboard]() Tags: [animations](), [apple](), [coding](), [gui](), [implementing](), [interaction](), [ios](), [ipad](), [keyboard](), [sdk]() ### AI overview A guide to implementing mouse and trackpad pointer interactions on iPadOS 13.4. It covers the relevant APIs, setup requirements, UIHoverGestureRecognizer, and hover animations while noting that iPad pointer behavior differs from macOS. ### Source excerpt Gui Rambo writes about his coding and reverse engineering adventures. ## The 16-inch MacBook Pro DevFeed: [The 16-inch MacBook Pro]() Original publisher: [Read original article]() Author: Marco Arment Published: 2019-11-13T13:30:08Z Content type: opinion Language: en Sources: [Marco.org]() Topics: [keyboard](), [Hardware](), [reliability](), [Resilience]() Tags: [apple](), [hardware](), [keyboard]() ### AI overview The author's first-day assessment of the 16-inch MacBook Pro is optimistic despite several unchanged shortcomings. The article argues that replacing the butterfly keyboard with scissor switches, adding a hardware Esc key, improving key spacing, and restoring the inverted-T arrow-key layout address the MacBook Pro's most important previous problem. ### Source excerpt After my first day with the new 16-inch MacBook Pro, I'm very optimistic about it. 🎧 Hear more on today's Accidental Tech Podcast! Two years ago, I wrote a wishlist to fix the MacBook Pro, and the 16-inch doesn't actually deliver most of it. But time and technological progress are slowly getting Apple off the hook: The ports are unchanged. We'll still need dongles. But USB-C is gradually becoming more common, and dongles are slowly -- very slowly -- getting less shitty. The Touch Bar isn't optional. But a new hardware Esc key removes one of its biggest drawbacks, and accidental input should be reduced by the increased spacing between the Touch Bar and the top row of keys. The power brick still lacks its previous conveniences. There's still no cable management, safety breakaway, or charging LED. But third parties are slowly filling some of these gaps. The headphone jack is still on the right (wrong) side, despite most single-sided headphone cables entering the left earcup. But the need for wired headphones is decreasing over time. Addressing those would be nice, but as I wrote then, they paled in comparison to one huge issue: the butterfly keyboard. The MacBook Pro must return to scissor keyswitches. If Apple only changes one thing about the next MacBook Pro, it should be this. It's far more important than anything else on this list. [...] The Magic Keyboard's scissor switches feel similar, but with a bit more travel, and all of the reliability and resilience of previous keyboard generations. [...] The Magic Keyboard only needs one change to be perfect for the MacBook Pro: returning to the "inverted-T" arrow-key arrangement by making the left- and right-arrow keys half-height again. This arrangement is much more natural and less error-prone because we can align our fingers by feeling the "T" shape, a crucial affordance for such frequently used keys that are so far from the home row. That's exactly what they've done, and I couldn't be happier. The new 16-inch MacBook Pro is ## The iPad Pro's keyboard limits comfortable typing away from a desk DevFeed: [The iPad Pro's keyboard limits comfortable typing away from a desk]() Original publisher: [Read original article]() Author: Eddie Smith Published: 2017-06-24T00:00:00Z Content type: opinion Language: en Sources: [Eddie Smith]() Topics: [iphone](), [keyboard]() Tags: [apple](), [iphone](), [keyboard](), [productivity]() ### AI overview The author argues that the iPad Pro remains difficult to use for serious typing away from a desk or table. Despite using the iPad frequently, they prefer the MacBook Pro for lap typing and the iPhone for some writing tasks because both offer more suitable keyboard forms. ### Source excerpt Even though Gabe and I sometimes have slightly differing views on the iPad's productivity value compared to the Mac, with his latest post, I think we are completely in sync--metaphorical Chris Farley falls and all. In particular, he nails a massive friction point for me with the iPad: I can type more comfortably on my iPhone than I can with my iPad Pro on the couch, in bed, or even just reclined in the backyard. I'm sure there's a good case out there that will solve this problem, but I'd rather see Apple solve it. I've tried using various keyboards for my 13" iPad Pro, but I've never found one that let me comfortably type while sitting away from a flat table or desk. This has been a huge failure point from a practical perspective for me because the iPad, by design, begs to be used away from conventional "work stations." So the irony is that the only time I can do serious word creation on my iPad is while sitting at a desk or table. If I want to escape those confines, which is a frequent want, I use my 13" MacBook Pro, which has the same form factor as the big-big iPad, but allows for lap typing. Like Gabe, I also find myself in the funny position of using my iPhone to type more, even when my iPad is at hand. A great example: if I'm reading a book on my iPad, it's actually easier to write notes about the book using my iPhone. I even wrote this entire post in Drafts on my iPhone at the breakfast table. My iPad is in sight across the kitchen. I still use the iPad a lot, but its use cases for typing still remain very limited for me. The Mac and iPhone just have superior keyboard forms. ## How the keypress Event Differs Between Chrome, Safari, IE10, and Firefox DevFeed: [How the keypress Event Differs Between Chrome, Safari, IE10, and Firefox]() Original publisher: [Read original article]() Author: Monica Dinculescu Published: 2015-06-02T00:00:00Z Content type: article Language: en Sources: [Monica Dinculescu]() Topics: [keyboard](), [browsers](), [Chrome](), [Firefox](), [deprecated]() Tags: [browsers](), [chrome](), [code](), [deprecated](), [firefox](), [keyboard]() ### AI overview This article examines inconsistent keypress event behavior across browsers. Chrome, Safari, and IE10 emit keypress for printable characters, while Firefox 38 emits it for all typed input. It also discusses differences and deprecation involving keyCode, charCode, and key. ### Source excerpt The keypress event works maddeningly differently in Chrome/Safari and Firefox, and this is the story of how I spent two hours discovering that, so that hopefully you don't have to. Keypress what? A keypress event is one of the events you get when you mash on the keyboard. It's special because according to the spec, you should only get a keypress event for keystrokes that produce printable characters. So you'll get it for things like letters and symbols, but not for backspace and left arrow. It's a great event to have if you want to write some as-you-type validation on an input, and you want to be able to dismiss the non-printable characters (which will still generate key events, but are uninteresting to the validation bit). Chrome, Safari and IE10 agree with this interpretation, which is great news. To be contrarian, Firefox (38; I don't know about Aurora) always sends a keypress event for anything you type. It's basically a keydown event from what I see. Now you have to get rid of control characters yourself and you get write code that doesn't make sense on the other platforms! Yay! (not yay) I call shenanigans. Mind your keyCodes and charCodes From looking at the spec, we expect a keypress event to have: keyCode, a number code that represents the key you've pressed. For example, q is 113. This is allegedly deprecated, but don't worry, both Firefox and Chrome implement it, but differently. charCode, the unicode number of the key. This code only exists for keypress. Like before, it's deprecated, but like before, it's implemented by both browsers. Differently. key, the value of the key represented by the event. According to that spec, this one is unimplemented. Worry not, Firefox implements it just fine (Chrome doesn't). It is the hero we deserve, but not the one we get right now. 😭 What you get out of this is spectacularly annoying. I wrote some code that basically prints out what the keypress event looks like, and found: As promised, in Chrome/Safari/IE10, we only ## Developing on Linux DevFeed: [Developing on Linux]() Original publisher: [Read original article]() Author: Zoli Kahan Published: 2014-09-13T05:00:00Z Content type: opinion Language: en Sources: [Zolmeister]() Topics: [Linux](), [configuration](), [Development](), [dotfiles](), [Shell](), [Atom](), [Hardware](), [keyboard](), [Bash](), [Nvidia](), [GPU]() Tags: [4k](), [configuration](), [editor](), [git](), [gpu](), [hardware](), [keyboard](), [keyboard-shortcuts](), [linux](), [nvidia](), [oh-my-zsh](), [zsh]() ### AI overview A personal account of a Linux development setup covering the i3 tiling window manager, ZSH with oh-my-zsh and Powerline, Atom as an open-source editor, and desktop hardware requirements. ### Source excerpt Developing on Linux dotfiles i3 - Tiling Window Manager A tiling window manager is a type of window manager that arranges your windows as tiles, usually in such a way that makes managing them more efficient via keyboard shortcuts. i3 is my window manager of choice, after having used xmonad for a long time, i3 provides more flexibility and ease of configuration. Here is a great sceencast which will help you understand the power of tiling window managers. ## My setup: Hardware DevFeed: [My setup: Hardware]() Original publisher: [Read original article]() Author: Graham King Published: 2013-12-07T23:46:58Z Content type: opinion Language: en Sources: [Graham King]() Topics: [Hardware](), [pc](), [cpu](), [ASUS](), [Linux](), [Nvidia](), [monitor](), [keyboard](), [Wi-Fi](), [Programming](), [Ethernet](), [webcam]() Tags: [asus](), [behaviour](), [cpu](), [desktop](), [dual-screen](), [ethernet](), [hardware](), [keyboard](), [linux](), [monitor](), [nvidia](), [setup](), [video]() ### AI overview A programmer describes a personal hardware and office setup, including desks, an Aeron chair, dual ASUS monitors, a desktop PC, an SSD, Linux-compatible graphics hardware, networking equipment, audio devices, a webcam, and input devices. ### Source excerpt "Geek chic: A witty tour of one programmer's hardware setup." ## Kinesis Advantage after four months DevFeed: [Kinesis Advantage after four months]() Original publisher: [Read original article]() Author: Graham King Published: 2013-12-07T22:58:09Z Content type: opinion Language: en Sources: [Graham King]() Topics: [keyboard](), [Microsoft](), [Linux](), [Vim](), [USB]() Tags: [keyboard](), [kinesis](), [linux](), [microsoft](), [software](), [usb](), [vim]() ### AI overview The author reviews four months of using a Kinesis Advantage keyboard after years with Microsoft Natural keyboards. The transition was difficult for the first three days, but typing became faster and more comfortable by the end of the first week. The author also discusses its compact size, use across desktop and laptop setups, and configuration for Linux, Vim, and tmux. ### Source excerpt A keyboard love story: still typing after all these years.