A release of a new major version of WordPress means its time to review my plugins to ensure they remain compatible. I also take the opportunity to fix any code style errors using the latest WordPress code style.
My plugins are feature complete, they do exactly what I need them to do, and so this time around the changes made to the plugins were relatively minor. The changes to the code in these are updates primarily targeted at code style errors.
I strongly believe that open source software needs to have a code style guide, and the code that I write for my plugins must adhere to the WordPress style guide as closely as practicable.
As always if anyone is using the plugins and notices anything wrong, or requires additional features, please let me know. Use either my contact form, or creating issues at the individual plugin GitHub repositories.
Reusing code is a core competency for any software developer, and is as simple as using an existing function, or as complex as integrating an appropriately licensed library. Such as a library or application released under one of the many Open-source licenses.
The most common way of reusing code is via copy and paste. It's the most easily used tool in the software development Swiss Army Knife.
Code is often copy and pasted from one area of the code base to another. Which is a bad habit that is the topic of a post all on its own. Most often code is copy and pasted from places like Stack Overflow where someone has asked a similar question and received a usable answer.
A risk when reusing code, especially when using the copy and paste approach, is that the code introduces bugs. The other day I reported a minor styling issue to a developer, and their response was:
I got that code from someone else and just put my code around it
This response bothered me, and I've had this post rattling around in the back of my mind ever since.
There is nothing intrinsically wrong with using the copy and paste technique. Used responsibly it can help solve the issue at hand, without reinventing the wheel. I've used it myself too many times to count.
It is my opinion that any one using the copy and paste approach, whether they're developing code for enterprise systems, or writing queries of ad-hoc reporting, needs to understand the code that they are writing.
Software defects, such as bugs in code, are an unavoidable part of writing software. This includes the most complex enterprise applications, all the way down to SQL queries used for ad hoc reporting.
Reusing code, especially that which is copy and pasted like in my example, becomes part of the code base that you are responsible for. Even if you are not the original author and have simply copy and pasted it into code.
From one developer to another, I ask you to please understand what you are reusing, and check that it doesn't create bugs. Especially ones that are easy to detect.
I wrote this plugin to make it easier to access my home server when I'm not at home. For a number of years I used a dynamic DNS service. I then decided that it didn't make much sense to pay for both web hosting and a dynamic DNS service.
Last year I wrote a Laravel based dashboard, as a way of exploring the framework, and part of the dashboard was a ping recorder. Earlier this year I decided to discontinue development of the dashboard, and focus my efforts on WordPress development. As a result I wrote the Techxplorer's Ping Recorder plugin in the hope that it proves useful for other people.
The plugin works by defining a special 'ping' URL. This URL includes a secret key. When the URL is access with the correct secret key, the IP address of the request is recorded. The recorded IP address is then used to construct a URL using the SSH protocol. So that when I click on the link, my Terminal program starts and makes an SSH connection to my home server.
So far the plugin is working really well for me, and I hope it proves useful to others. If you do use it I'd appreciate it if you left a comment below, or let me know via Twitter.
As you may know, I'm working as a business analyst in the Student Systems team at Flinders University. I've been in this position for a little over a year now.
Recently, I have been transitioning to a new position. I'm working as a business analyst as part of a project team. We will be making some significant changes to the Student Management system over the next year.
I have been working collaboratively with a colleague to map a number of existing business processes. We've been developing flow charts and cross functional flow charts to build business process maps.
Many of the project stakeholders have embraced our work, and we've made good progress in understanding the existing business processes. It has been exciting and challenging work, and I have learned a lot from my colleagues and project stakeholders.
There has only been one minor note of discord, which has prompted some reflection. The result of my reflection is this post. I have been reflecting on what I have decided to call, the 'pretty picture problem'.
During the workshops we draw the flowcharts on a whiteboard. All of the stakeholders have input, and the whiteboard is a powerful collaborative tool. After the workshop we take pictures of the flow chart on the board using our mobile phone.
Occasionally, the process that we are mapping is so complicated that we need to take photos at different stages of the process. Erasing the whiteboard each time to continue our work.
These photos form the basis for a more refined diagram that we produce in Microsoft Visio. We then share these diagrams with the stakeholders to seek further input and feedback.
The end goal is to have the stakeholders 'sign off' on the diagrams as an accurate representation of the current processes. The intent is to use these maps to identify ways that the new functionality in updated Student Management system can improve these processes.
On a small number of occasions I've had project stakeholders refer to the diagrams as a 'pretty picture'. A lot of time, effort and thought go into these diagrams. I feel that referring to them as a 'pretty picture' devalues our hard work..
It also makes me concerned that the stakeholder isn't engaged in the process as much as they could be.
I've been reflecting on the 'pretty picture problem', and what I can do to improve stakeholder engagement. At the moment my thoughts centre around three main points:
Make the diagrams as clear and concise as possible
Capture the existing business process as accurately as possible
Work with project stakeholders to see past the 'pretty picture' and to the underlying processes
Achieving this third point is a work in progress, and relies on using communication and collaboration to build a shared understanding.
I'm interested in what others who have undertaken this work have addressed this issue. Please let me know via the comments section below, or ping me on Twitter.
As regular visitors to my blog will be aware, I work at Flinders University, as a Business Analyst in the Student Systems Team. The primary system that I help support is the Student Management System, also known as a Student Information System. The other day I participated in a meeting that got me thinking about usernames, passwords, and user identity.
First a bit of background.
At Flinders University the centrally managed username for all staff and students, is known as a FAN. The acronym stands for Flinders Authentication Name. The exact origin of the acronym is lost to the sands of time. Students and staff use their FAN and password to access many centrally managed computer systems. For example, desktop computers, the WiFi network, email, and other resources. One historical exception to this is the Student Management System.
For various reasons, categorised under the heading of 'Vendor Supported Software', logging into the Student Management System by a student requires them to use their Student ID, and not their FAN. The Student ID is a unique number assigned to each student.
Over the past few months our team has had a focus on improving the experience that students have when interacting with our systems. This is part of a larger project at the university wide level focussing on a holistic view of the student experience.
One of the issues that we identified is that some students were having difficulty logging into Student Management System. Specifically they were using their FAN and password, not their Student ID and password. Anecdotally, our help-desk staff received many calls about issues related to the login process.
To address this issue we made a few minor changes to the login form.
First, we added custom validation rules on the form to restrict the Student ID field to only digits. This improved the user experience as it meant that they would get a more informative error message if they tried to login using their FAN. Second, we changed the name of the 'Password' field to 'FAN Password'.
This brings me to the meeting I participated in the other day.
We were discussing the login page and the fact that we had changed the name of the password field to 'FAN Password'. This raised the following questions, "Why did you do that? Wouldn't be easier to just say 'password'?".
Making the change that we did appears counterintuitive, because to keep the language on the form simple, the field should simply be called 'Password'.
I have been reflecting on the meeting and this change to our login page for a little while, and have the following thoughts.
A user's identity, from the perspective of a computer system, is their username and password. That is, to login to a system you need both pieces of information. They're linked together in that the password goes with the username. At Flinders University we always talk about the username as being a FAN. Therefore from the student's perspective the only place they can use the password that works with their FAN is in a login form that asks for their FAN.
The login form for the Student Management System was confusing for some of our students, particularly those who were new, because it asked for a Student ID, and password. The logical question in their mind was "What is the password that goes with my Student ID?". It couldn't be the one that they used with their FAN, because the login form is asking for their Student ID and password, not their FAN and password.
To help the user in using the login form, we renamed the password field to 'FAN Password'. The purpose of the change in the name of the password field was to make it clear that even though the login form isn't using their FAN, the student needs to use the password associated with the FAN. That is, their FAN password.
For someone focussed on reducing the text on the page, thereby making it easier to read and understand, the use of 'FAN Password' for the label appears to make the form harder to use. Whereas from our perspective, and from our students perspective, it makes it clear which password the student needs to use.
The Student Management System will soon be integrated with the centrally managed identity management and single sign on platform. When this work is complete, the need for students to login with their Student ID will go away, and with it the seemingly oddly named field on the login form.
The overarching conclusion I drew from my reflections is this:
In the mind of the users of the systems we manage, their username and password are strongly linked. One doesn't work without the other. As custodians of computer systems we need to take care when changing the terminology around logging in, authentication, usernames and passwords.
Lastly, using two possible values for a username, with the same password, is a cause for confusion, as typically a single username is strongly linked with a single password.
Ultimately this was an interesting topic to think about. If you have any thoughts on this issue, I'm really keen to hear them. Either get in contact on Twitter, via the contact form, or leave a comment below.
Unlike many other online courses, this course has a practical component. The first assignment of the course is a micro usability test. In essence, this is a test with a small number of targeted scenarios, using test subjects that are readily available. For example colleagues down the hall.
I won't go into which web site that we used for the assignment, because I don't think that is fair. What I want to write about is my reflections on the peer-assessment following the assignment.
I chose two colleagues to undertake my micro usability test. My two test subjects didn't have any trouble with the usability test and successfully completed all of the test scenarios.
Based on my own experiences, and that of my test subjects, my opinion was that the website had no significant user experience issues. The peer-assessment phase of the assignment challenged my opinion and the conclusions I had drawn from the tests.
In reading through the submissions from my peers, I came to see the flaw in my micro usability tests. They were reporting many more issues with the website. A common theme was that their test subjects didn't have as much experience with the Internet, websites, or the type of website, as mine had.
It became very clear that the results of my micro usability test were inherently biased towards experienced users. I found this conclusion very interesting, and I'm not sure it would have occurred to me without the opportunity to undertake peer assessment.
The lesson that I've learned is that user selection is a key element of any user experience test, and is especially important in micro usability tests. This is because user selection can have such a fundamental impact on the outcomes of the research.
As I alluded to earlier, micro usability tests are also called 'hallway' usability tests. This is because, just as I did, it is possible to select users from those walking up and down the hallway. In thinking about my experiences of this assignment, and the lessons learned, I think it would be better to go a little further afield. Perhaps to the next floor or next building.
It is something to ponder while I work through the course. I'm interested to hear what you think, let me know via Twitter or via the comment section below.
Earlier this week I participated in a meeting, discussing data issues related to an integration between two enterprise systems. Specifically, the people with a single name had their identity incorrectly represented.
Both systems have a distinctly western view of identify, where everyone has a first name and a last name. At the database level this means that there are two fields to store this information.
The integration between the two systems contains code that assumes that both name fields must contain a value. As a result, the integration code replaces null values in these two fields with a '.' character.
I'm not going to write about the various issues that people with names that do not fit into the 'first name - last name' pattern experience. Except to say that identity is hard from both systems development, and user experience perspectives. What I want to focus on is one specific aspect of user experience related to this issue.
One of the systems displays the 'first name' of the user as the label for a button that user clicks on to access their profile. The full text of the button is an icon and the contents of the 'first name' field. When the first name field is a '.' character, the button is very hard to use. Because it is small and contains only the icon and a '.' character.
One of the questions that we discussed during the meeting was whether the '.' label on the button was a worse user experience than a potentially really long label caused by a long name.
My recommendation was to not use the '.' as the label, and instead use the potentially long name provided by the user. My reasoning is that using the '.' makes it appear that the organisation doesn't care what the name of the user is. It appears that the organisation is penalising the user for not having a name that fits within the strict western view of identity.
A long label for the button may cause some styling issues, but it respects the user's identity. This, in my opinion, provides a better user experience.
In an ideal world there are two things that could be done to solve this issue.
First, use a single field for the identity information for the user. If this is impractical, provide the user with a 'preferred name' field, and use this field for display. Using this approach puts the user in control of the display of their identity. Ideally this field is only populated with the contents of the 'first name' and 'last name' fields, during the initial synchronisation.
Second, use a CSS rule to truncate the label on the button if it is too long and is going to cause styling issues.
I've worked with enterprise systems most of my career, and know that they are very rarely representations of an ideal world.
I acknowledge that this is my view, coming from someone who has had an interest in user experience for a long time, and has only just started a formal course in the topic. I am also someone who has a first name and last name, and so I can only try my best to see the world through the eyes of a user who has a single name.
If you have any thoughts on this issue, I'm really keen to hear them. Either get in contact on Twitter, via the contact form, or leave a comment below.
The discussion topic for week one of the course is good and bad User Experience (UX).
When talking about good UX one of the videos in the first week used words like:
Easy to learn
In contrast when discussing bad UX the video used words like:
In thinking about the discussion topic for this week, I thought about my recent experiences with software that I could describe using these terms. I eventually settled on Apple Pages and Microsoft Word.
I am one of only two people in my team who use macOS for their day-to-day tasks. Part of my role relates to writing documentation, and for that I predominantly use Apple pages.
This is because many of the 'good UX' words apply to my use of the software. I can produce high quality documents with a minimum of effort. The most commonly used features are always at my finger tips. I don't feel like the software is 'getting in the way'.
This is not to say that I miss some features. For example the inability to have multiple tables of contents, or different page layouts in different sections, is annoying at times. I feel that the software development team behind Apple Pages pared it down to the essential functionality. As with many applications from Apple, it also is very attractive in terms of look and feel. It is also tightly integrated with the overall operating system.
In contrast Microsoft Word makes me think of all of the 'bad UX' words. I always feel like I'm hunting around looking for the right piece of functionality, which is typically buried in a menu tree. I often feel like the software is 'getting in the way' and making life difficult. Fortunately Clippy, the Office Assistant, is no more. But the overall experience for me is frustrating.
I feel that software development team behind Microsoft Word have tried to add in every piece of functionality that they could think of that a 'enterprise user' would need to use. This focus on trying to do everything comes at the detriment of the 'average' user who only needs a subset of all of the different features. I also feel that it is not as integrated as well into the overall operating system as Apple Pages is.
In reflecting on this comparison, it occurred to me that there is a fundamental difference in the way that two development team view their users.
The focus of Apple Pages is on the user as an individual. A myriad of places online have said that Apple is all about the consumer, and not the enterprise. Whereas Microsoft is all about the enterprise. It is possible that it is this focus that makes all the difference.
What I mean by this is that a user, from the perspective of Apple, is the individual. Whereas a user, from the perspective of Microsoft, is the enterprise.
It is this distinction which I hope to explore further as part of my studies for the MicroMasters program. I'll write about this idea more here on my blog I'm sure.
Last month I successfully completed the English Grammar and Style (Write101x) course from edX and received a verified certificate. I undertook the Write101x course to help improve my writing, and now it is time to learn more about user experience research and design.
Listed on the certificates page here on my blog, are the other online courses that I've completed.
One of the problems I have with online courses, as I've noted in the past, is the use of discussion forums in online courses. I find that the significantly high number of posts are a deterrent to adding new, and reading existing, posts in the discussion forum. The signal to noise ratio is too low, and so I've not posted regularly.
This is a problem, as it means I miss out on the structured reflection that posting in the discussion forum provides. To address this, I am going to publish the posts I write in the discussion forums here on my blog. As well as other reflections on the course.
My aim in doing this, is to increased my participation in the course, as well as provide evidence of my engagement with the courses and learning outcomes. I will be posting my first discussion forum post, and subsequent blog post, here in the next few days.
I look forward to exploring the topic of user experience research and design, and seeing where this journey will take me.
Yesterday the family and I visited Adelaide Zoo. Not the best day to go as it rained in the early afternoon. Before it rained I had the opportunity to get some good photos.This is the last gallery of photos from the visit. This is Asrar a Veiled Chameleon.
Asrar a Veiled Chameleon at Adelaide Zoo
Asrar a Veiled Chameleon at Adelaide Zoo
Asrar a Veiled Chameleon at Adelaide Zoo
Asrar a Veiled Chameleon at Adelaide Zoo
Asrar a Veiled Chameleon at Adelaide Zoo
Not the best set of photos I'll admit, it was a little too dark and I had the wrong lens on my camera (I'd left the other lens at home). But Asrar was too beautiful to not at least attempt to get some photos.