Post

Laying A More Solid Foundation – Themes & Customization Part 3

January 1, 2019
Leave a reply

Happy New Year! This is the third in a series of posts I’ve been writing about where I think site customization and theming in WordPress could go next. If you haven’t already, check out the previous posts cause we’ll build on those ideas in this post.

Quick disclaimer: At the time of writing I’m doped up on cough syrup (for a legitimate cold) so if anything here doesn’t make sense, let’s just blame it on the drugs.

In this post I want to talk about a much less sexy but foundational area of the theme: How the HTML document gets rendered. You may not think about it much but themes literally have the final (almost) say in what makes it from WordPress to the browser for every single page, post and archive on your site. While this gives them the maximum freedom, it also creates a problem for site customization: inconsistency. There are literally millions of themes available and they all are structured sort of the same, and sort of differently. From a customization perspective, this makes sites very unpredictable. Does a theme allow full-width content? When does it add title headings automatically? Can I create a special page with no header? Each theme is slightly different in how it handles these common issues. 

You’ve likely had the experience where you find a theme somewhere for a new site you’re working on and it seems great visually. Maybe you’ve even purchased it. Then you crack open the files and realize that the person who wrote it, at best, didn’t read the theme authorship handbook as closely as they should have and, at worst, is a total nut who has structured the theme in a way that defies all human reason. Things are tightly coupled together, stylesheets are being hardcoded instead of enqueued, there’s duplicated code, never mind not having been updated to support 5.0 yet, and worst of all – nothing is documented. Theming WordPress today offers lots of opportunities for inconsistency and human error. These same issues make site customization a moving target because the agreements between the theme and the core system concerning layout are not well-defined. But we could change that.

Disclaimer: Before anyone thinks it sounds like I’m trying to take creative capabilities away from themes, let me say that I’m a designer, myself, and I’d never advocate a change that limits the kinds of sites that can be created with WordPress. I believe adding some well-designed guard rails to the system has the potential to make theme authorship faster, more stable and easier to learn for beginners while enabling creators to focus on the unique areas of their site design. So stay with me.

Who Owns The Document?

As I stated before, currently themes control the HTML document 100% from the <!doctype html> to the </html>. Traditionally the document is started inside the header.php template part and completed in footer.php. Assuming a site only has one header and footer style, each template within the theme is expected to include both files at their beginning and end, respectively. Right off the bat we have an opportunity for a malformed document. If any of the templates in our theme forget to include one or the other, not only will the page be broken, but WordPress’ own frontend UI can’t function properly. Take a look at the structure of the index.php file in the new Twenty Nineteen theme. I’ve combined and abbreviated what’s happening inside the header and footer for clarity.

The index.php template for the Twenty Nineteen theme isn’t all that complex

You can see that the structure is not actually very complicated. But what’s unique about this particular template? Which parts are different from every other theme? The <head> contains a few meta tags. There are some wrapper elements. There’s a screen reader anchor. Apart from that, these are your basic hooks that are required for WordPress to render properly. Setting aside the meta tags for a moment, the actual unique areas of this page all happen inside the <body>. The content loop is your basic “if we have posts: this part, else no posts: that part” kind of statement. The most unique thing about this layout are really just the wrapper tags. So why are we writing all this?

A greatly simplified index.php file that only deals with what’s inside the <body> tag.

What if this template could just look like this(above) and the system did the work of rendering the base document for us? We’re telling the system where to place the actual header and footer. We’re telling it where the content needs to be placed but letting it handle the logic of when there are or aren’t posts (check out the “Block Areas” post for more on that). We’ve set up the wrapper elements we need for semantics and styling. And because there are no tags split across files, we’re not in any danger of having broken HTML because we forgot to include something. Giving the core system responsibility for the base document also completely removes the burden on the theme author to correctly include nearly all of WordPress’ hooks. In this scenario there would be no need for a theme author to be aware of hooks like body_class() or wp_head(). The system can insert those transparently.

What About Those Meta Tags?

The meta and link tags are the only actual unique parts of this <head>

The remaining unique part of the template are the two meta tags and one link tag that are being inserted explicitly. One of them is the charset which is expected and better handled by the system anyway. The other two set up how the site behaves on different screen sizes and a relationship link. But think about what’s not here. We already (should) enqueue scripts and stylesheets and let wp_head() output them for us. More recently we even let the system output the <title> tag for us if the theme declares support for it. Link and meta tags are the obvious missing piece. We should create an API for declaring those so our document head can be completely managed by the system. 

There are several benefits to letting core completely render the <head>. First, it removes the need for a theme author to be current on the latest SEO trends when it comes to metadata. We want designers to do what designers do and marketers to do what marketers do without stepping on each other’s toes or feeling like they have to know ALL the things. By not hardcoding things like meta tags, social card data and micro formats, a theme could stay relevant longer and require fewer updates over its lifespan. By the same token it would allow the entire data structure of the <head> to be filtered by plugins that do things like tracking and optimizations. There would never be a need to override header.php in a child theme simply because it’s putting in or not putting in the proper tags. Finally, consider alternate document structures like AMP. An AMP page requires a different doctype, styles and scripts to be limited and loaded in a specific order and scripts need to be loaded asynchronously. Currently this requires the entire template to be filtered and replaced. Giving core control over how the document is formed opens up lots of future-proofing options for new formats.

Back To Site Customization

I said before that the unpredictability of themes limits site customization, so what new things could we do if core owned the document? First, this restores the header and footer template parts back to their intended purpose: being actual headers and footers. A theme could offer one or more header designs that could be swapped in and out without altering the base document markup. This could also allow us to show no header or footer at all which is frequently useful for one-off pages like landing pages. Themes generally have to create a special custom page template for that. In my first post in this series I showed this mockup describing how the system might let you visually choose between different header designs that the theme offers.

A customization screen offering the ability to change headers visually

This becomes a lot simpler to achieve because our header template parts are just the headers themselves. They no longer contain the opening document. This is something a theme would have to implement custom logic for today, but it could be out-of-the-box behavior in the future.

One thing that’s always been a friction point for page builders and now for Gutenberg as well is that a theme may not offer the full page width for designs that require it. The Twenty Seventeen theme, for example, has a very narrow column for the post content. We now have a theme support declaration for gutenberg blocks that offer wide and full-width styles, but what if the core system could ensure that, when requested, the page content could have the full width of the browser? Again, this eliminates one of the reasons that themes often add custom page templates named things like “Blank” or “Full Width”. While we’re in the neighborhood, printing the post title automatically, while not directly related to the base HTML document, falls into the same category of things that could easily be handled in the content output with an option to disable it on a per-page basis. This further enables the “full page canvas” style to happen when desired. It’s a feature that virtually all page builders have had to implement for themselves (hiding titles with CSS usually) and core could offer a better, more consistent way of handling it across all themes.

What if we don’t need that extra wrapper markup in the Twenty Nineteen example above? What if the layout is simply a header, the content area, and a footer? Do we really even need the template file? Why not just express it declaratively like this:

<?php
register_template( 'index', [
  'header',
  [ 'name' => 'content', 'show_title' => false ],
  'footer',
]);

In many cases just declaring your intentions to the system is enough for it to know what to do. Maybe there’s even a valid use case for having no theme active at all 😱? When the system is able to render the document on its own, lots of interesting things become possible.

Here’s a crazy thought. What if we wanted to build a fancy single-page site that when you click an internal link, it transitions to a new page without refreshing? This is pretty hard to do now because you need to render the full page to be sure it’s complete. But if we know the base document doesn’t need to change, just the layout, and we could diff the <head> data structure, this becomes a much simpler problem to solve. Instead of that being part of a theme itself, a feature like that could be something a plugin offered that worked with virtually any theme that opted into core document rendering. This gets especially interesting when you look at using service-workers to cache fragments of pages.

There’s a great Steve Jobs quote from way back in the NeXT days where he said:

The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.

He was referring to how the then NeXT Interface Builder application (now part of Xcode) synthesized UIs so that app programmers didn’t have to write them explicitly. I really think this is how we should be thinking about WordPress as well. What are the common patterns in themes that core could offer some consistency and help theme authors focus on just what’s unique about their design? Are there common pitfalls that we could eliminate entirely? How can we grow WordPress not just toward being a great content publishing experience, but a first-class site design and development platform too?

Quick Recap

  • Themes today are inconsistent and unpredictable
  • Let’s create a new way to opt-in to core rendering the HTML document so themes can focus on what’s inside the <body>
  • Let’s decouple header and footer parts from the opening and closing document structure and let them simply be headers and footers.
  • Let’s explore new customization experiences like template part swapping and automatic full-width support without needing custom page templates.
  • Let’s explore ways to declaratively register templates when having the php file is overkill.

If you have thoughts on where you’d like to see themes and customization go next, I’d love to hear about it! Also if you want to see all the mockups I’ve done for this post series, they can be found on Dropmark – https://brentjett.dropmark.com/617450

Post

Block Areas – Themes & Customization Part 2

December 28, 2018
Leave a reply

If you haven’t already, check out part 1 of this series – https://brentjett.design/2018/12/20/a-fresh-look-at-customization-part-1/

In the first post of this series I showed some examples of a new site customization space that I think would improve several areas of WordPress. In subsequent posts I’m looking at different technical aspects of theming to make those ideas either possible, or more manageable. I strongly believe that themes and customization are two sides of the same coin and during this Gutenberg Phase 2 exploration time, both should be looked at together.

So we have blocks now. Gutenberg’s atomic unit is the block and the post content makes great use of it. The question of where blocks go next is certainly being thought about and this question directly impacts themes. How will themes expose new editable regions? Where do these initial block layouts (because nothing should ever look empty) come from? Matt alluded to these ideas in his State of the Word keynote in December. As the concept of blocks has the potential to subsume previous structures like widgets and nav menus, there’s a companion idea that has equal potential. Block Areas.

A block area is a portion of the overall page layout where blocks exist. This is both simple and extremely powerful at the same time. We need a way for themes to designate regions of itself that can be manipulated with blocks if the user chooses. Themes also need to be able to specify what the initial block structure of those areas is. Let’s look at an example.

A new customization space showing nav menu editing

The image above highlights a nav menu area that could be edited with blocks. It isn’t hard to see how a block area might replace the traditional Nav Menu Location. Themes simply specify a block area called “Main Nav” for example, and optionally include a block layout for the initial menu structure. The code for adding a block area might look something like this:

<?php
do_block_area( 'main-nav', [
  'label' => __('Main Nav', 'example'),
  'scope' => 'theme',
  'layout' => [...]
]);

This declaration tells the system where the block area is placed, what to call it, where to save its data when edited (we’ll talk about scope in a bit) and what its initial state should be (a block layout).

Block areas could be useful for more than navigation though. Remember that good ole’ content loop we’ve been writing forever? Have you ever tried explaining the post loop to a new theme author that has never programmed before?

<?php
if (have_posts()) :
   while (have_posts()) :
      the_post();
      the_content();
   endwhile;
endif;

What if instead of that, we just wrote this:

do_block_area('content');

Wouldn’t learning theming be much easier? And block areas don’t need to be any less capable than explicit code. What if we exposed a way to give these areas a “no content” layout, for example and let the system decide when to show what? There are many many ways the core system could make this experience simpler.

Scopes and Capabilities

Block areas can be used for quite a few different things, but one important aspect to define is scope. A block area that outputs the post content is different on every single post, and any changes made to it’s layout should be saved to the post_content field in the database. Conversely a nav menu might exist at a global level, the same on every page and thus should be scoped to the ‘theme’ or ‘site’. Telling a block area how to save itself when changes are made through UI is essential.

Here’s another example. Let’s say your page layouts have a “hero” area. This hero area might show and hide based on whether the author adds a featured image to the page/post. But why make this separate from the content layout at all? Well, what if the technical details of how the hero works weren’t up to the author user? What if the admin wanted to lock that capability away? Block areas offer an intuitive user role barrier between different sections of a layout. This way any content author can add a featured image or not, but an editor or admin has the ability to edit the block layout of the hero itself, and do something totally different in that space when they desire. The content author never needs access to that particular area. If an admin edited a post, he’d see the full set of blocks defining the hero and can change them as desired. Defining this block area might look something like this:

do_block_area( 'hero', [
  'label' => 'Hero',
  'scope' => 'post',
  'capability' => 'edit_others_pages',
  'layout' => [...],
]);

There are so many different things block areas could be useful for:

  • Header & Footer Parts
  • Nav Menus
  • Widget Areas
  • Heroes and Pre-Footers
  • Modals and Interstitials
  • Post Archive Layout
  • Login Page Layout
  • 404 & Maintenance Layout

Block areas offer a simple mechanism to make the theming APIs more concise, easier to learn, and yet more powerful at the same time. New customization experiences could be built on top of an API like this and a new generation of themes could make WordPress even simpler to approach and use.

In part 3 of this series I jump into how to set a more solid foundation for themes. https://brentjett.design/2019/01/01/a-solid-theme-foundation-customization-part-3/

If you’d like to see all the mockups I’ve done for this series, I’m throwing them in Dropmark for now and will be adding some new ones along the way. https://brentjett.dropmark.com/617450

Post

A Fresh Look At Customization – Part 1

December 20, 2018
4 comments

I had the pleasure of going to WordCamp US earlier this month in Nashville and hearing Matt speak at the State of the Word and talk about what comes next for WordPress. I also had several fun conversations with members of the community (we have the best community!!) and now that I’m back home, it’s left me thinking a lot about what I would imagine next for WordPress if it were up to me. We’re at such an interesting place in WordPress’ history. Blocks have arrived but we’re still waiting to see what they become and where they might be useful beyond the editor. The WordPress community as a whole is in a learning mode right now because there’s so much new functionality and code to familiarize ourselves with. Many things are in transition and up for debate.

One area that I’ve been thinking about for a long time is the relationship between themes and customization. I don’t think I’m alone in that. The advent of blocks calls into question the role of themes and how we’ll be creating websites with WordPress for the next decade. Phase 2, or the next big focus in WordPress is still a bit fuzzy as to what it’s going to look like. We know we want blocks inside nav menus and to bring widgets into conformance as well, but beyond that it’s not a clear picture yet. The customizer, meanwhile, is looking a little long in the tooth. It was born out of a different set of theming problems and it’s written with technologies that, while excellent in their own right, have largely been passed over for their newer, more modern alternatives. Even the way in which we structure programs has changed dramatically since customizer was first created.

What if WordPress had a new customization space?

A customization space with multiple workspaces for organizing controls.
A new customization experience that is divided into multiple “Workspaces”

It isn’t unusual for me to sit with a cup of coffee, dream about stuff, and draw. That’s what I’ve been doing here lately. I decided to try and use the visual vocabulary from Gutenberg (with plenty of creative license taken) and see if I could form a coherent thought on where I think customization could go. We know we want a new experience for dealing with navigation menus and widgets. We know there’s some notion of using blocks in layouts but what does that really mean? And then there’s the question of how do we rescue themes from their identity crisis and give them a fresh purpose in a component-driven world. 

Asking for one design to address all of these ideas is a tall order. But so is asking the customizer to do the same. The tension I’ve always felt in customizer is there’s no sense of tasks. You could argue that panels are meant to do that, but it still leaves me wanting more clarity, more of a sense of place. What am I doing right now and what controls or visuals do I need to do it? Am I choosing the layout for my blog? Am I setting up the typography for my site? I want a way to tailor those experiences more to the headspace that the user is in at that moment.

That’s what led to me to the notion of “Workspaces”.  The user should be able to switch between different perspectives of the same application with different tools and controls. Each workspace could present the site preview like customizer does now, or some other screen that’s more appropriate to the task. Each workspace could have its own set of panels that you can navigate between. One workspace might need the sidebar, another might not. One might highlight things inside the canvas that the user should notice. 

Before diving into more mockups and ideas I think it’s worth noting that my instinct with application design is to start with the ideal user experience and work backward to the technical constraints. This lets you kind of run fast and dream big, then worry about the realities later. There are a few different user scenarios that I think it’s good to keep in the back of our minds when talking about customization in WordPress:

  • The experience a first-time user gets when they land in a new WordPress site.
  • The experience a designer/creative has when they are trying to use WordPress to implement a specific site design.
  • The experience an author has working on content (hey Gutenberg 👋🏻)
  • The experience an advanced user has when managing, optimizing, and maintaining a site over the course of its lifespan.
  • The experience a creative has in making a new theme to be published on the repo or shared.

 There are certainly more use cases than this, but these are the ones on my mind.

So What Could Workspaces Do For Us?

One of the things I think could be greatly improved upon is the user’s relationship to layout choices. Gutenberg introduces a way to register a block layout to be used as a starting point for pages and I think it’s only natural that this functionality will find its way into other places eventually. Wouldn’t it be great if themes never had to create a select control with “One Column” and “Two Column” options again? Could this new customization space:

  • Offer the layout options from the theme in a more beautiful, intuitive way
  • Offer choices of multiple header and footer parts and let the user decide when they get included
Choose one of the available templates to configure – Blog Layout in this case.
Choose from a set of available headers to use for this layout

I’m always looking for more ways to be visual. I would love to be able to choose “Edit Header” and have the UI render all my options so I can really make an informed choice. This isn’t the simplest thing to do technically but we won’t worry about that right now.

Where Does Styling Go Next?

If there’s one quintessential thing that a customization space has to do well, it’s help you style your site. The customizer gave themes a way to surface design options that it could synthesize into html & css. But one thing customizer never did is give you a view of all the styling patterns that your theme supported. For that you’d have to read through the stylesheet and try to make sense of it. It’s now the responsibility of themes to also style the core blocks. 

I’ve heard lots of chatter over the years about design systems, living style guides, pattern libraries and in general I think these are all really good things when they can be explained visually. What if WordPress had a formal set of layout patterns for themes and blocks to use AND what if we also had a built-in test sheet to actually see that our theme is covering all the bases?

The style workspace presenting a style guide layout and controls to configure the default library

I personally would love to see WordPress take a more opinionated approach to styling and remove some of the burden from theme authors. Authors can always override things with their own styles but out of the box, you shouldn’t need to. Even better would be a library that the customization experience already understood and could offer options like spacing, base text size and of course, content width. These could be configurable through controls and the appropriate css would get generated.

In addition to the style controls, we could present one or more style guides to show the user what patterns are available (as blocks, or just html/css) and offer theme authors a consistent set of testing content without having to import a testing suite into the database and go look at a bunch of different pages. And oh by the way, the style guide could be built with blocks (just sayin’).

Most importantly, this offers a space to show what’s available in a theme. If it has color options, let’s show that. If it has created multiple block styles, let’s show those too! MOAR Visual!

Who’s Got Nice Assets?

Very closely related to styles is the topic of assets. Most of the themes I have written in my career have had to include some design assets in them. Also there are some kinds of image assets that we just can’t upload to the media library like SVG art and WebP images (for security reasons). What if we gave themes and plugins a way to declare what assets they have in them, and let the system present them where appropriate? These might include:

  • Icons
  • SVG art
  • Color Palettes – we already have a form of this in Gutenberg
  • Typeface options – both included font files and 3rd party services like Adobe Fonts (formerly Typekit) and the Google Font Library
  • Appearances and Color Alternates – this bears further explaining, but what if we helped themes do things like dark and light appearances for their designs?

We want creatives making good design choices in their themes and then offer them to be used by everyone else, right? Why not give them a first class experience for showing off that work?

Asset Library Workspace displaying what’s available to be used

The asset library could be the culmination of any theme or plugins that have registered assets to be used by the system. Then in appropriate places, the system could offer those choices, like when styling for example:

Style workspace showing a font control in the sidebar
A new font picker panel that shows available fonts organized into groups

I won’t go into too much detail about assets here; I’ll save that for a dedicated post, but I think giving themes and plugins a formal way to declare their design assets and then presenting those in the UI would go a long way to making WordPress feel like more of a vibrant, creative platform.

In The Beginning…

One area that we’ve never been able to tap into is the “5 minute install”. It kind of makes sense. There are no themes or plugins active at that point so even if there were hooks you wouldn’t be able to use them. But what if after install, or the first time a new user logs in they could be guided through a simple intro experience? What if themes could offer some options to take you through upon activation?

Choose how you want to begin using WordPress
A theme could offer customization options that it wants a user to see upon activation

Before you ask, yes, I do have a “Use Without Theme” option in that first screen, and no, that is not possible in WordPress today. Should it be? In part 2 of this post I might talk about that a little. But more importantly we could offer some really nice walk-throughs for new users this way. 

How Might 3rd Parties Use Workspaces?

Possibly the most exciting area for me (not surprising, since I work for Beaver Builder) is opportunities for plugins and themes to create brand new experiences that weren’t possible before or were impractical. I think the notion of workspaces could open up a lot of good things here. Let’s take site optimization for example. 

We all know we need the boring bits: SEO, Tracking, Image Optimization, Redirects, etc… but where do you put that stuff? The admin makes sense for a lot of it, but what about when you need the context of the page view to really make sense of the options? How about an optimization workspace?

A menu could offer a choice about which workspaces are visible at any given time. Complexity Managed!
An optimization workspace to highlight issues to be resolved

The idea here is a dedicated space to highlight issues that need to be resolved and give an expected place for things like tracking scripts and micro-formats. Core might even define the workspace and have a few checks of its own. I know there’s a project sometime this year to get the theme health check plugin into core. We could really use a place for that.
The benefit of putting these things in their own workspace is it’s a natural separation for user roles. The users that need access to styling and navigation probably aren’t the same ones that need to be looking at tracking and redirects. Workspaces provide a natural place to separate functionality by user role.

How do we get there?

If you’ve made it this far, you’ve probably already started thinking this is a pretty big idea and working on it would be a pretty big project, and you’re correct. An undertaking like this would have to be broken into pieces and accomplished over time. It also would require some changes under the hood to make these kinds of experiences possible, or at least more manageable. In the next post in this series I’m planning to dive into what kinds of things might need to change technically to make user experiences like these possible. Thanks for reading!

Keep Reading

In Part 2 of this series, I look at how themes might declare “block areas” for use in customization. https://brentjett.design/2018/12/28/block-areas-themes-customization-part-2/

Part 3 explores setting a more consistent foundation for theming and customization – https://brentjett.design/2019/01/01/a-solid-theme-foundation-customization-part-3/

Also if you’d like to see all these mockups in one place, I’m throwing them in Dropmark for now and will probably be adding some new ones along the way. https://brentjett.dropmark.com/617450

Post

This’ll do.

May 19, 2018
Leave a reply

As per usual, I’ve fallen off the map for months at a time. This time I’ve sprung back up in Plano, Tx. Bentley and I are settled in and enjoying some morning adventures, one of which led us to this sunrise. Well done, God.

BJ306333.jpg

Bentley seems to have discovered a way to make his ears levitate. Also I think his nose may be getting longer.

IMG_2582.jpg

Last week Mom and I took a field trip down to the Dallas Arboretum. Apparently every school child in DFW also took a field trip there that day, but it was fun nevertheless.

IMG_2518.jpg

IMG_2510.jpg

Working on some fun new stuff I’m not ready to talk about yet, but as per usual, hopefully I’ll be blogging and vlogging again soon. Texas is heating up quickly so some indoor creativity might be in order.

IMG_2466.jpg

IMG_2470.jpg

That’s all for now!

Post

Vlog #7 – This is why you rent cameras | Beagle Weekend | Sony a6500

January 30, 2018
Leave a reply

I figured while I have the a6500 for a few more days I should turn around another quick vlog. I love renting new gear to play with. The a6500 is a great camera, but I think it really just made me love my a7ii more. Plenty of beagle in this one too. Enjoy.

Also, this is the face looking at me while I’m filming these.

DSC00231.jpg

And a little black a white while we’re at it.

DSC05855.jpg

And if you missed last week’s vlog check out here!

Post

Vlog #6 – Love the a6500, Hate the RX100 V, Slow-mo fun in the woods

January 27, 2018
Leave a reply

Managed to get Vlog #6 out tonight. I’m trying out the a6500 for a few days and so far it’s a pretty sweet camera. This is my first go at slow-mo footage (120fps) but I’m learning fast hopefully. See what you think.

I love this particular trail that runs behind my apartment and I’m trying to really soak it in before picking up and heading to Dallas in April. This turned out to be a nice shot, rather mirkwood-esque I’d say.

DSC00205.jpg

The a6500 is a pretty impressive camera. I’m not overwhelmed by the stills just because I’m used to the full-frame a7ii but after spending a day with it, the a6500 is no slouch. Hopefully the video above speaks for itself.

And of course, a camera test wouldn’t be complete without some beagle in it.

DSC00037.jpg

DSC00048.jpg

That’s all I got for now.

Post

Dealing with frustration using photography

January 23, 2018
Leave a reply

When I’m frustrated with what I’m working on, I play with my camera. This morning it’s After Effects that is sending me back into the warm embrace of my Sony a7ii. I’m just going to come out and say it: After Effects’ user experience blows.

DSC05829.jpg

I don’t use lens hoods. They just sit on my desk.

DSC05834.jpg

First beagle photo of the day. There will be more

So I’m new to After Effects and attempting to learn it, but I’m also a UI designer and while I like a good dark UI, my issue with After Effects’ UI is that it’s TINY. Like ridiculous tiny. There are so many little toolbars with icons shoved together and then large sweeping fields of space where there’s absolutely nothing. This is the worst use of screen space I’ve seen in quite a while. Now I know that they have to shove a lot of crap into this thing to make it work for video guys, but come on. Where’s the UI scale preference? Where’s the intelligence to say “Hey look, this guy has a big-ass 5k monitor, maybe lets spread out, why not”? Come on Adobe, this isn’t your first time.

Screenshot 2018-01-23 09.49.09.png

All I’m saying is how can there be this much junk on the screen and I still can’t figure out how to set a keyframe? End of song.

Post

I’m a wimp when it’s cold

January 22, 2018
Leave a reply

DSC05734

I sprang out of bed on Saturday ready to go to the Dog Park, partly because Bentley and I had been cooped up inside the house for four freezing cold days but also because I was ready to take some pictures of dogs. I keep trying to get decent dog pictures out of my Sony a7ii. The a7ii is generally the best camera I’ve ever owned and I absolutely love shooting with it, but I’ve had a few situation where the autofocus lets me down, and trying to focus a dog running toward the camera from a few feet away has been one of them. Anyway, I was excited to get to the dog park to take some photos and it sounded like the weather was going to be nice. But as it turned out it was cold, windy, wet and generally gross and I, having only worn a hoodie, spent the entire time shivering and complaining instead of actually attempting to make a photo. Long story short, the only image I got was this one on the way there of Chloe being anxious while Katy was inside a gas station, but ya know, it’s not half bad.

The moral of this fairly mundane story is that there still, in 2018, is no such thing as a perfect camera. You pick them for what they give you and what they’re good at. All it takes is one fun, unexpected shot to renew your deep and undying love for your camera…until the next model comes out.