Added By: Feedage Forager Feedage Grade B rated
Language: English
button  concerns  consistency  css  deep work  deep  design  don’t  it’s  i’ve  keyboard  modal  new  people  time  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics

Tips, Tricks and Bookmarks on Web Development.


Matias Wireless Keyboard

Mon, 20 Mar 2017 14:29:41 +0000

I don’t normally do product reviews but the Matias Wireless Keyboard looked like a great addition.

The Matias keyboard has the same layout as the full wired Apple keyboard—with full-sized arrow keys and full number pad. But it’s wireless!

The keyboard comes in colours to match your MacBook. In my case, I got the Gold. They've done a good job of matching the style.

The keyboard takes about 5 hours for a full charge and should last for up to a year before needing to be charged again (according to the box). Best thing is that it can be charged and be used at the same time! (This shouldn’t be a novelty but considering neither the Apple Magic Mouse nor the Apple Pencil can be used while charging, this is something special.)

Overall, it has a similar feel to the older wired keyboard with a similar amount of travel. (I believe the newest Apple keyboard is closer to the newer Apple MacBooks.)

Another really nice feature that really clinched it for me is the ability to connect the keyboard to 4 different devices. With a quick tap of the button, the keyboard will switch over to that device. I currently have the keyboard linked to my Mac, my PC, and my iPad Pro. It takes about a second for it to connect, which has been barely noticeable when switching devices.

When connected up to the Surface, the function keys work but the media keys don’t. Speaking of connecting to the Surface, it took a few tries before it even saw the keyboard. Once it found it, though, it worked fine.

One last thing to mention about the keyboard is that I can feel the printing of the letters on the keys. I can’t think of a keyboard I’ve had in the last decade where that's been the case. It doesn’t really bother me—at least, it hasn’t yet.

(Thanks Kitt for ordering the keyboard for me!)

Attempting Deeper Work

Sat, 18 Mar 2017 17:08:18 +0000

I’m in the midst of reading Deep Work. I’m about two-thirds of the way through and while it’s probably a bit hasty to jump into a review, I have been thinking about what it means to how I work and what I want to work on. The concept behind the book is that for the knowledge worker, success comes from the ability to think and work deeply on something. Basically, to get into a state of flow. This is extremely difficult for me with my constant need to read Twitter, Facebook, Instagram, Slack, and whatever else I think needs me attention immediately. Deep Work describes how we need to train our minds to resist shallow distractions. More than that, we need to develop a routine so that these shallow distractions don’t deplete our ability to attend to things deeply. I’m currently looking at my schedule to see how I can structure my day, to think less about what I should be doing at any given moment, and to think more deeply about the task that I know is at hand. The temptation is definitely there to just give up on social media altogether—especially with the onslaught of negativity that pervades the platforms right now. I believe I still get value from these platforms and can also provide value back. Thus, I don’t plan to give them up outright. I do need to restructure my relationship with them, though. And I haven’t determined the best way to do that, yet. The Schedule 07:00 Day Prep 09:00 Deep Work 10:00 Break 10:30 Deep Work 11:30 Lunch 13:30 Deep Work 15:00 Research 16:30 Disconnect 19:00 Reading Day Prep attempts to normalize days I do and don’t have my kids with me. I get up, get them ready, and off to school. When I don’t have them, this is time I can use to go get a coffee, chill out, or do whatever. Maybe practice some meditation. I want to avoid using this time to be on my phone because I don’t want to deplete my attention energy at the beginning of the day. Meditation in some form or another would be ideal. (The book talks about different forms of meditation that can be helpful.) Although it’s only two hours worth, I’m trying to front load my time for deep work. The intention being that I won’t already be mentally fatigued and thus, more able to get into a state of flow. The lengthy two hour lunch lets me go out to grab a bite to eat or stay in and prep a meal. If I have extra time, I can deal with email and other social media. This would be the first time of the day in which I would do so. After lunch, I have my next big block of time to focus on Deep Work. This brings the grand total to 3½ hours. That’s not a lot but hopefully the increased focus during this time will bring greater gains. Lastly, I cap off the afternoon with some research time. This is shallow activity time. This could include social media time, as well. After all that, the early evening routine, again, attempts to normalize my days with and without my kids. When I have the kids, we’re doing dinner and homework. When I don’t, maybe I’m getting groceries. Or hanging out with friends. Or just relaxing with a book. I wasn’t really sure what to do with the end of the day. Do I spend this time back on social media? Is there anything else that might fit in here? Having a routine of daily reading sounds ideal. Basically, finish off the day with something to sleep on, letting the subconscious process things. Weak Spots When I first put together my schedule, I noticed I only had an hour and a half of deep work time by the time lunch rolled around. Putting most of my deep work time in the afternoon might mean I’d already be too tired to get into a state of flow. Thus, I switched things around to at least get a bit more time. I could use more but I think it’d mean getting up earlier and I’m not yet sure I want to do that. How do I deal with identifying and dealing with urgent matters? If I get a text from my ex that I need to pick up a sick kid from school, do I potentially go over an hour before even noticing that[...]

CSS Concerns

Fri, 03 Mar 2017 14:43:58 +0000

These days, I often find myself hearing people say “we use BEM” or “we use SMACSS” and the question that often comes to mind is “how exactly do you use them?” Coming up with a catchy name for a development approach is a double-edged sword. On one hand, they are a convenient way to convey a lot of information really quickly. If someone says that they use BEM, I can make some quick assumptions. On the other hand, people are people and often interpret the details differently. The devil is in the details. Like Ajax and RWD, BEM and SMACSS and OOCSS have, to some degree, become overloaded terms and it’s hard to tease out what someone really means when they say they use these techniques. Long gone are the days when people actually transmit XML in an Ajax call. People create fixed width designs for three viewports under the banner of Responsive Web Design. Likewise, people use atomic classes with a BEM naming convention. (And don’t get me started on naming conventions!) In reality, what I’ve found is that I have specific concerns that I want to address and that I use particular techniques to address those concerns. People don’t often think consciously about these concerns. I know I often don’t. But it can be useful to understand the priorities on a project and what techniques you choose to address those priorities. My Concerns (when developing with CSS) My concerns when it comes to architecting an application often are: Consistency: How can I maintain consistency in my design and development? Clarity: How can I make it easier for people to understand what I’ve developed? Efficiency: How can I speed up development? Change: How can I make it easier to make changes? UX: How can I improve the user experience? The Salesforce Lightning Design System talks about their design principles. Salesforce lists these in order of priority. It’s useful to articulate your priorities as they help you make decisions during the design and development process. Obviously, when it comes to CSS architecture, I have opinions. The way I chose to solve those problems was by using the concepts I laid out in SMACSS. I’ve never explicitly mapped the concepts to the concerns I’ve listed above but I can see how the concepts address those concerns and why the concepts were important to me. Consistency I care about consistency within a given page and I care about consistency across an entire site. I believe that a consistent experience is easier for users to understand, thus creating a better user experience. Clarity When I talk of clarity, I mean of how easy is it for other developers (or future me) to understand the work I’ve done. Can a new team member ramp up quickly? Can a developer building out a new interface do so without stumbling their way through it or missing critical steps? Efficiency Being able to build new features or redesign existing ones easily in an established system is important. If teams ignore parts of the app or take months to refactor things because of poor design or infrastructure then everything else suffers—users, employees, and employers are sad because it takes longer to get features out the door. Change Change ties into both efficiency and consistency. When it comes to growth within a design system, I believe it important to be able to maintain that consistency as designs change. It’s also important to be able to roll out design changes quickly. If it takes a large team weeks or months to roll out a new design then this pulls them away from working on new features. In some orgs, I’ve seen global design changes take a back seat to new feature development, further exacerbating the situation. New features either take on new design elements, breaking away from site consistency, or they continue to stay with an old design, increasing the amount of work required to roll out a new design. User Experience Lastly, how will the user experience be affected by any of the above? For example, if I improve a widget experience [...]

Coding CSS for Context

Fri, 10 Feb 2017 15:15:57 +0000

Dave Rupert recently tweeted asking a question that I see quite often: .some-context .thing { /* special rules and overrides */ } Does that go in thing.css or some-context.css? Then, Harry Roberts discussed this concept further in his article of CSS Code Smells Revisited. Harry uses a practical example of .thing being a .button. (Well, actually, a .btn but whatever. And yes, I just “well, actuallied” myself. It’s preemptive mansplaining.) You’ll have the standard button that appears throughout your application. And then you have this variation in modal dialogs. Instinctively, we start writing .modal .button. Hence, Dave’s question of where to put this particular bit of code. It’s interesting to note that the results of Dave’s survey indicated that a slim majority of people prefer that this bit of code live in with the modal CSS and not with the button CSS. Harry indicated that it should live with the button CSS. And I agree with him. We’re styling a button! It should be in with the buttons. But then Harry seemed to contradict himself by saying that the button class name should be renamed to .modal__btn, making it a part of the modal component. In doing so, this bit of CSS should now live in with the modal CSS. (And based on naming convention, I would agree with him.) One thing you have to worry about is components becoming too complex. Yes, the modal has a button. It could also have inputs and headings and all sorts of things. Over my career, I’ve noticed useful boundaries and tend not to create components with deep hierarchies. Identifying The Thing Going back to our thing that we’re trying to style: the button. Yes, right now, we’re styling a button in a modal dialog. Is this the only place that this exists? Right now, quite possibly. Will it always be the only place it exists? If your project is constantly in flux, then not likely. Here’s what’s important: We want to identify that this is a variation on our button. We want to indicate the purpose of this button style. We want to avoid tying the code to a particular context that could change. Going with .button--modal, for example, now identifies it as a variation. But fails on the other two points: It indicates its context and doesn’t say what it’s trying to do other than be in a particular place on the page. So, why is the button in the modal different than regular buttons? (If you’re the designer, ask yourself this. If you’re not the designer, ask them this.) You might get something like, “It needs to be green to draw attention to the fact that it’s a primary action.” Or maybe something like, “the button is smaller because we don’t have as much room.” This helps you come up with a name like .button--primary or .button--compact. Either of those names satisfy the three points I mentioned above. It identifies itself as a variation using the BEM double hyphen. It indicates its purpose through the variation name. It hasn’t tied itself to a specific context. That last point, to me, is the most important. As a designer, I might end up using these styles on a new page that hasn’t been thought up yet. I might want to use a primary button style on a form that isn’t in a modal dialog. I might want to use a compact button in a sidebar where I don’t have a lot of room. And as Harry also mentioned, by keeping all our button styles in one place, we have the ability to see patterns emerge across an entire project. Three months down the line, do we suddenly find ourselves with 30 button styles and need to reduce the complexity of our UI? That can be harder to do if button styles are strewn throughout the codebase, hidden within other contexts.[...]