Development – Page 6 – Chris Koerner

Smart Albums for iPad Air Screenshots

A few years ago I wrote this tip on creating Smart Albums for your iPhone or iPad screenshots. I’m a big screenshot taker. I use them for keeping track of UI problems with projects I’m working on and even as a quick “note” to look into something later.

The problem is sorting the screenshots out from the rest of my 80 billion photos in my library. I use Aperture (yes, me and two other people) and created this Smart Album to sort out my screenshots from my iPad Air. You can probably adopt the logic for other devices as well.

Screen Shot 2014-08-22 at 4.04.59 PM

Basically it looks for files that match all of the following:

Text starts with “IMG_” – standard filename prefix for iOS device screenshots.
Pixel height and width is between 1,536 and 2,048 – this allows for both portrait and landscape screenshots to be returned
Camera Model is empty – pretty much all of my other images are photos from cameras that record their model. iOS devices do not store a value for “Camera Model” in their EXIF data.
File Type is other – no RAW or jpegs showing up here!

If you have suggestions or modifications, please let me know in the comments below.

Cognitive Biases in Software Engineering

“This is one of the harder biases to get over in my opinion, because it means acknowledging our own limitations, and really stressing the fragile parts of the code that we write. We all want and expect our software to work, so we are inescapably drawn to evidence that confirms this desire. Keep fighting this urge, keep testing, and always question your assumptions.”

Jonathan Klein on how our brains deceive us when encountering issues in software development.

Fleeting Thoughts on Design

I wrote this for some internal documentation around or data visualization (i.e. Dashboards) standards. I kind of like it.

Gas-pump-ui

Here’s something you may use every week, a gas pump. Most people probably don’t think much about how it was put together.

This is a perfect example of something made without much cohesive design. Every gas station is different, every pump manufacturer, every point-of-sale vendors, etc. Each with its own design decisions and logic. We learn to deal with these inconsistencies every time we stop for gas. In the worse case we become frustrated or make mistakes due to the lack of consistency. In the best cases all parts are easy to understand and work consistently.

In the physical world there is a long and complex history in the development of interfaces – multiple owners, physical and technical limitations, regulatory influences, etc.

However, even with those differences, we all know how to navigate this process. We’ve developed knowledge of what parts of the display we can interact with and how certain parts need to be selected first before seeing changes elsewhere.

The same is true in the digital world. People have come to rely on a lot of subtle clues to make their way through an interface: buttons have slight gradients and rounded corners, links have hover states, form fields have a soft inner shadow, and navigation bars “float” over the rest of the content.

These consistent elements are the focus of our user interface (UI) standards – the things we can make consistent should be consistent regardless of creator or audience. We have the unique opportunity, unlike the beleaguered gas station pump designers, to work together to create a shared language and experience when creating content for our co-workers.

Using External Data and the MediaWiki API to Build a List of Popular Wiki Pages

For one of our internal MediaWiki installations we used the DynamicPageList extension to show a list of the most popular page on our wiki’s main page. We found it to be handy to have an at-a-glance view into what’s the most utilized content. However, we recently upgraded to a newer version of MediaWiki (1.23) and were having issues with DPL. As such our list disappeared while I worked on another solution.

What I discovered is that you can use the External Data extension paired with the MediaWiki API to produce a dynamic list of Special:PopularPages¹

First to understand what the API query looks like. Here’s what I’m using:

https://yourwiki.org/w/api.php?action=query&list=querypage&qppage=Popularpages&qplimit=10&format=xml

Breaking that down, we’re asking to query (action=query) the API, return a list from a page (list=querypage) and defining which page (qppqge=Popularpages). Then we set some limits and formats (qplimit=10 and format=xml). Note: You can even use an offset (qpoffset=5) to display multiple selections of data combined with the limits.

Then, on the page you want the list to appear add the following External Data syntax.

{{#get_web_data:url=https://yourwiki.org/w/api.php?action=query&list=querypage&qppage=Popularpages&qplimit=10&format=xml
|format=XML
|data=Title=title
}}

<div>{{#display_external_table:
template=PopularPagesExtAPITable
|data=title=Title}}</div>

That syntax says get the data from the API query, format it as XML, and match up the value for Title to a local variable of title.

Then, we use #display_external_table to format the results using a template. The <div> and other syntax is for styling the results.

In the template, this case named PopularPagesExt, we have the following:

<li style="list-style-type: none;">[[{{{title}}}|{{{title}}}]]</li>

This says for each result returned in our #get_web_data query make it a list item, apply some styles (in this case removing bullets), and then use the returned value as a standard wiki link – [[Page Name|Link Text]]

The link text is the same as the name of the page. Makes sense, no?

The result is a dynamic list of Popular pages that you can place on any wiki page.

Seth Godin on Being Satisfied Creatively

“Are you satisfied creatively?

Not even close. That’s a very dangerous place to be and it would truly depress me if that happened and I would get very scared as well. I think if your goal is for everything to be okay, that’s a mistake. To achieve that goal, the only obstacle you’d have to face tomorrow is to eliminate all risk so that everything would be okay. I’ve made the decision that I’m never trying to make everything okay. I’m trying for there to be more loose ends, not fewer loose ends.”

https://thegreatdiscontent.com/seth-godin

Today I’m making motion graphics in After Effects, tomorrow I’m setting up a new site for a client in WordPress, the day after, who knows!? While it does afford a certain level of discomfort, I’d much rather be pushing myself than complacent with just one domain.