Categories
code development

Why is CSS hard?

CSS is a real language, and you need deep technical knowledge to understand it. But plenty of software developers hate it and look down on it. It’s a good, if incomplete, tool for what it does. But I think it scares some of the gatekeepers who were drawn to software before the web.

It can’t be unit tested. It’s a language that only exists in a domain that stretches multiple sizes, multiple devices and multiple renderers. There’s more than 1 way to do things. And some of the biggest challenges with CSS are human. It’s the paintbrush for the bike shed.

https://twitter.com/craignicol/status/1074330589107507200?s=19

Funny how many hard problems in computer science, including cache invalidation, are about users.

Advertisement
Categories
code development ux

Blank spaces : how to deal with nothing in API design

Consider the following HTTP endpoint:

GET /{user}/appointments

How do we deal with nothing?

Nothingman

🚫 If the user doesn’t currently exist, return 404 – this informs the caller that nothing can be done with this resource until it is created or recreated.

🙈 If the user exists, but we want to protect against username enumeration, return 404 – this removes a route for malicious agents to identify actual users, perhaps prior to a password brute force. They may decide this endpoint is less likely to have the full protections afforded to the login endpoint. This endpoint should also avoid indirect enumeration, for example returning immediately for “user doesn’t exist” and delayed for “user exists but we’re pretending because security”

🔒 If the user exists but the caller doesn’t have permission to see their appointments, return 403 – caller will have to login, or ask someone who has access.

Empty time

Given the selected user exists

🔐 If this user does not support appointments, return 404 – these resources can’t be found.

🗓 If this user does support appointments, but there are none, return an empty list.

note : some APIs will return 204 No Content in this scenario. 204 should only be used for POST or PUT requests to indicate server action was a success, and there’s no data to send back

Empty space

Given the selected user exists
And they have at least 1 valid appointment (see business for what “valid” means)

📺 If the appointment has no location (because online conference links are saved elsewhere in the appointment body) then no location property should be returned

❔ If the appointment has no location (because it is unknown) then the location property should be returned with no data (the empty string)

Categories
cloud development programming

Cloud thinking : Executable documentation.

Documentation is just comments in a separate file. At least developers can see the comments when they change code. Tests are better comments. Tests know when they don’t match the code.

Infrastructure is the same. I can write a checklist to set up an environment, and write an architecture diagram to define it, but as soon as I change something in production, it’s out of date, unless it’s very high level, and therefore only useful to provide an outline, not detail.

Unit tests document code, acceptance tests document requirements, code analysis documents style and readability, and desired-state-configuration documents infrastructure. All of them can be checked automatically every time you commit.

Documentation as code means the documentation is executable. It doesn’t always mean it’s human readable; ARM templates in particular can be impenetrable at times. If machines understand it, the documentation can be tested continuously, repeated endlessly across multiple environments, reconfigured and redeployed at the stroke of a keyboard.

The more human you have in a process, the more opportunities for human error. It doesn’t remove mistakes, but it’s much easier to stop the same mistake happening twice.

Categories
development programming

Modular doesn’t mean interchangeable

Microservices are great. Containers are great. Packages are great. Objects are great. Functions are great. At each level they encapsulate functionality into re-usable modules. One place to make changes. One place to optimise. One abstraction to help you move to the best layer.

For the sake of argument though, I’m going to focus on microservices, specifically those accessed via an API, as that’s what I know best.

Interfaces and APIs are good for test harnesses, but isolating systems for your own benefit (to make modules open for extension but closed for change) bears no relation to making that module useful to other systems.

Sure, I could rip out the modules that contain business logic, and package it as a framework, but that doesn’t mean it’s useful for anyone else. It could well be an inner system . It may still be coupled to domain/architectural knowledge that make it too valuable to swap out. There could be an implicit dependency for just that one version of that one tool.

It is of course possible to make modules re-usable, but they have to be designed that way, whether up front, or evolved. And anything interchangeable has to be tested, in at least 2 conditions, to make sure it’s suitably robust.

Design an interface. Evolve the design. But don’t mistake solving one problem in one place for a general solution. And don’t think that adding an interface is all it takes to turn a local SQLite data store into a cloud file system repository.

Categories
development

Inclusion is not a zero sum game

Look around your office. How many people look like you? How does that compare to the people you saw on your commute, or in the supermarket? How does that compare to your users? Do you even know?

Are you making space?

How many people are struggling with mental illness? How many have accessibility challenges? How many are white, straight, cis-gender, able bodied men?

Is there a mismatch? And if so, what are you doing to change it? Are your job adverts inclusive and on inclusive sites? (hint: look at the StackOverflow developer survey before posting your job there) Do you have a network outside work that you can tap into to find new candidates?

Are you creating a safe space for everyone? Are company events open to new parents, to non-drinkers, to vegans, to women? Do people have to out themselves to attend a family day, or to avoid travel to a certain customer site? Do you support staff who need to transition? Staff who need quiet spaces? Staff who are fasting, or need non-Christian holidays?

Can your staff find somewhere to learn to sign? Or to write simplified for language learners, for those who have struggled to attain or retain language?

Which three of these questions are the most important to achieve for you this year? And how will you do it?

If you need somewhere to start, have a look at Inclusive 101 from the Microsoft Inclusive Design Toolkit, and ask yourself if that’s you, or pick an episode from the Cause a Scene podcast and listen, especially if it makes you uncomfortable.

Categories
development

New Job : Welcome to Screenmedia

Following my request across my network looking for a new job, I started at Screenmedia 3 weeks ago. For those who don’t know, it’s a digital design practice, which means I’m back to consulting, and I get to work with a lot of smart people, covering technology and design. I’m a Technical Architect in the integrations team, so that’s APIs, voice assistants, serverless, analytics, so should be a good wee adventure. I’ve got a few thoughts on the job hunt which I’m sure will come up at ddd.scot and future blog posts. But if you’re currently looking, we’re hiring. If you’ve got any burning career questions, the DDD Scotland panel survey is still open.

I’ve been working on lots of interesting projects already, so groking multiple domains, sometimes multiple for the same customer, Checking the checklists, and reviewing the onboarding process. Sometimes the best change is the one that lets you re-evaluate what you think you know.

 

 

Categories
development programming

Cloud thinking : storage as data structures

We’ve all experienced the performance implications of saving files. We use buffers, and we use them asynchronously.

Azure storage has Blobs. They look like files, and they fail like files if you write a line at a time rather than buffering. But they’re not files, they’re data structures, and you need to understand them as you need to understand O(N) when looking at Arrays and Linked Lists. Are you optimising for inserts, appends or reads, or cost?

I know it’s tempting to ignore the performance and just blame “the network” but you own your dependencies and you can do better. Understand your tools, and embrace data structures as persistent storage. After all, in the new serverless world, that’s all you’ve got.


Understanding Block Blobs, Append Blobs, and Page Blobs | Microsoft Docs

 

Categories
development ux

User Experience : A quick introduction for developers

The following is an internal summary I wrote for a team that no longer exists, summarising a number of references from UXScotland, various book and blog posts. It extends the thoughts from my Pecha Kucha talk. For more details, please refer to the links throughout and the references at the bottom. The context here is consulting and long-term B2B projects, but some of these discussions are more widely relevant.

User Experience : Project considerations

User experience is about making sure we are solving the right problems in the right way. It is the intersection of design, users, and context. Context here is a combination of one or more of the device in use, the user’s location, any social cues such as nearby friends, and anything else that may be available from sensors or historical information.

vennux

In many cases, the requirements we have are assumptions (e.g. what users want is Facebook integration). Where the benefits of a requirement are unclear, we should treat it as an assumption to be tested. Embrace data, and analyse it.

At the requirements stage, we need to make sure we are solving the right problem (pretotyping : “building the right *it*”), and that our chosen design helps the user to solve the problem without frustration (i.e. prototyping the design, rather than the implementation, with wireframes/sketches).

In user testing, particularly in an agile development, we can refine those ideas by seeing how well the implementation solves the problem, by testing with users. We can also test deployed code by analysing heat maps and http logs to see what users are doing to inform further tests and the assumptions that feed into further design cycles.

In a Lean/Agile project, we need to be explicit about our assumptions about the user and test them at every stage of the development to ensure that we always meet user needs.

cycleofux

How does UX fit in our process?

Stakeholders

A system that supports user’s need effectively will need to understand that the user is a Stakeholder in the process. Whilst the users themselves may not be directly involved in the generation or review of design artefacts, there should be a user representative, either a super-user on the customer side, or a 3rd party researcher who has determined user needs, and has authority to verify any proposed solution and high-level requirements against those needs.

Functional Requirements

Personas / Typical Users

A persona is an abstraction of a system user. In a simple system, there may be only one type of user, but more sophisticated systems will typically have users and administrators, and may have multiple classes of each. A persona is defined to encapsulate the types of tasks a specific user may wish to perform, and any limitations that may be imposed (for example, administrators may be able to install specific browsers or client software, but members of the public using the system must be supported across multiple browsers at multiple screen sizes).

User Journeys

Each persona will have one or more tasks they wish to perform in the system. A User Journey describes the tasks as a series of steps that a specific persona will follow in order to achieve that task.

Consider the tasks that a user wants to perform. See also BDD – design from user in.

E.g.

User wants to process a case:

  • User logs in to the system
  • User selects case from their task list
  • User reviews latest document
  • User finds agent for case, and calls to discuss
  • User adds comments to case
  • User saves case and returns to their task list

This process may identify a new use case (“Display task list”), and specific actions that need to be defined within a use case (“Display latest document” and “Display agent contact details”)

The User Journeys provide the context between the Stakeholders (and User Types therein) and the Use Cases. Each User Journey will link to one or more Use Cases, but some Use Cases may not have an associated User Journey (nightly payment processing, for example).

User feedback

If the solution is replacing or improving an existing system, the best source of information on the current system are the users. The requirements capture process should take into account both the tasks that the users perform and gather feedback on any areas of frustration. The prioritization exercise should consider these improvements as well as new functionality.

Testing

As well as testing the Use Cases for functional acceptance, the FAT/UAT process should also test that the final system supports the User Journeys defined up front.

On-going support

Where projects have regular support meetings, the input of users has been valuable in identifying problems areas and possible changes. When on-going service delivery contracts are defined, SDMs should consider whether ongoing user feedback is appropriate as part of the planning and scoping of releases within that framework.

Questions to ask

  • Have the requirements been tested on users? If not, why not? (Are these the right requirements?)
  • Will users be given the opportunity to provide feedback on these through the development? (And if so, how, when and where?)
  • What user outcomes are we trying to achieve with the release? These may not be requirements that we put a cost on, but an expectation that we can measure against to show improvement – we would need to communicate this appropriately.
    • E.g. minimise clicks to access the 5 main functions
    • E.g. reduce time-to-complete for function x, y and z by 10%
    • E.g. Align existing UI with iOS and Android norms
    • E.g. Increase usage of function z by 5%
    • E.g. 99% AAA compliance
  • Who represents users on the project team?
    • How many user types do we need?
    • Can normal users and administrators share UX, or are their goals divergent? – different apps, different ASP Areas, different branding, …
  • What platforms and form factors need to be supported/tested?
    • Does each platform need a native UX? If native app, probably yes, if web app, maybe.
    • If mobile, do we need to adapt to context : location/orientation/communication with nearby devices/…
    • If social, do we need to adapt to context : can I approve my own work?/who’s online/recommendations/who’s nearby/…
  • Do we, as developers, have any input to the UI design? If not, why not?
  • Have the designs been tested on users? If not, why not? (Does the UI fit user expectations?)
  • Do we have appropriate guidelines for the appropriate platform, and are they listed in the requirements and estimates?

Potentially useful resources

 

Categories
development ux

Little UX wins #littlejoys

I’m no expert in user experience. So I’ll let others talk about the personas, the end to end journey and bringing joy. I want to talk about the details.

Those papercuts that slice away at you, that just make things a bit more work. The things that spending 15 minutes watching users makes you scream at yourself for putting your users through it.

But it doesn’t just affect technology. Here’s a list of papercuts I’ve noticed, either because one company has fixed them, highlighting the pain that everyone else puts you through, or because they annoy me. Reflect on your experiences as a user. What delights you and annoys you?

Things I like

  • Waitrose Meat in foil trays store the sachet in the cardboard cover, outside the foil tray, so no meat juice on them. This is a great example of separating concerns so that the raw, unsafe meat never comes in contact with the sauce until it has been cooked to make it safe.
  • Double tap to wake. The on button on many phones is small, and often hard to reach when on the table. Phones that allow a full screen action to wake take advantage of Fitts Law and their large screens to make that common action much quicker.
  • Lenovo N22 carrying handle. Many people carry their laptops without a bag. When you have a cheap, light, knockabout laptop, embrace it, and give it a handle. Bonus: teachers can carry many at once.
  • There’s also a bundle of wonderful examples here: UX out of electronic spaces http://uxpa.org/upasiteredirect/index.html/uxmagazine/lets-get-physical/?utm_content=bufferea7eb&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer

Less good

  • In my house, there are some lockable windows and some button operated (for fire safety upstairs)). On the button windows, you push and then turn. On the lockable ones, you turn the key to release the button, then turn. Every time, I push the button to open those windows, see the locked window depressed and think it’s unlocked. Every. Bloody. Time.
  • Something that needs better feedback rather than relying on transferable knowledge that many people are bad at : estimating size. Why does no microwave rice have a visual indicator of 2cm for the tear? So many packets have “tear here” and printed perforation. Why not “stop here”?

What papercuts have you seen, and what user experience interactions give you joy?