I am excited to introduce, History^χ (v2.4.0), an open source Chrome extension that I have been sporadically working on this past week. In the project manifest (and on GitHub), it is described as an “extension to enhance your browsing history experience”. But more specifically, it is an extension which, when enabled, will replace your existing history page with one that is leaner, and expanded with functionality.

It is ideal for regular, and power users alike. The former can take advantage of the improved interface, and smooth materialesque browsing experience, while the latter can take advantage of the search, sort, group, and filter features.

You can install v2.4.0 in the Chrome Web Store now or download the source, and run it in developer mode.

Background

The key motivator behind this extension is my dissatisfaction over the currently available options (I will elaborate on this later), and my desire for a history page that can allow me to sift through my historical web visits quickly.

As a web developer, and someone with a mild obsessive-compulsive personality disorder (OCPD), I often find myself trying to retrace my previous visits to recall what I have done recently / in the past or trying to locate a website that I vaguely remember. For example, occasionally something may trigger me to remember a specific phrase from an article I have read or perhaps a well-designed component from a website. I will subsequently have an urge to locate where this ambiguous “memory” was derived from so I can properly take note of it or share it (yes, I have a bad tendency to hoard information online, and I have way too many bookmarks). The only way I can achieve all this is through going back in time with what I can remember (e.g. keywords, pages I visited before / after, dates, etc).

This extension was built to cater for that need. After all, sometimes what I find unimportant, may become useful in the future. But obviously, since this is quite a complex need, it does have a lot of [planned] features that can help accomplish a bunch of other needs.

Features

History^χ supports the basic listing, deleting, searching, and paging feature that you can find on the default browser page.

Additionally, you can:

• Change the amount of results per page;
• Filter the results by date through a user-friendly calendar (you can also browse between months, and years quickly by selecting the calendar’s header);
• View the total number of results, and the current range of results you are viewing;
• View the total number of times you visited a page;
• View the specific time you visited a page;
• Access the paging controls at the top or bottom of your results (unlike the default page which only allows you to do this at the bottom of it);
• And much more!

Tip: select the current date to toggle filtering by date.

At the moment, the results are in chronological order. Over the next couple of days (or weeks) however, I will be rolling out support for sorting (e.g. by hostname), and grouping results (e.g. by hour).

Future

Going forward, I intend on implementing internationalization (il8n) through Chrome’s chrome.i18n infrastructure. Support for il8n however, is likely to come later as I am hoping to optimise the existing code base, and work on ways to streamline the existing workflows. I am looking to shorten the time, and effort needed to perform common tasks by both the user, and the computer (this will potentially involve caching, and fat-cutting).

At the time of this post’s publication, omnibox (i.e. autocomplete), tagging, and saved searches are other major features I have in mind for this extension. You can find out more by viewing the roadmap in the official project repository.

There are no plans for other browsers.

History^χ vs. other extensions

So, why should you use this extension vs. other history extensions?

First, unlike most Chrome extensions, this extension is entirely open source.

There are no ads. There are no trackers. It is completely transparent, and non-intrusive.

You can fork the project, improve it, personalise it or simply just investigate it to validate my claims. Alternatively, you can run your own copy if you do not trust me.

The closest competitor to this extension is tracking your every action via Google Analytics.

Furthermore, as it is open source, you do not have to wait very long for a bug to be patched or for a feature to be added. And if you have a background in JavaScript, you can even do it yourself. The project is being actively developed (or at least I hope it will be even long after I am unavailable to lead it), and feature requests are welcomed.

Indeed, in The Cathedral and the Bazaar (1999) by Eric S. Raymond, he succinctly describes what he calls Linus’ Law, that:

Given enough eyeballs, all bugs are shallow.

Second, it relies on a modern UI library, and web architecture that have been tested in large production environments.

It is not running on a complex spaghetti bowl of dependencies, and jQuery plugins. Each component, action, store, constant, and utility are isolated in their own file. This will allow you to follow the logic, and trace problems more effortlessly. It also makes it easier for new features to be added.

Several similar extensions are running on outdated libraries, and conflicting dependencies. Consequently, its developers will find it hard to maintain their code base, and to eradicate unpredictable behaviour. For example, one extension I have used for my history page (before this development came along) has been prone to crashes, and long load times. This problem has not been resolved for several months (although, this might be linked to my point about the nature of open source software).

Finally, results are not omitted.

Due to a limitation in chrome.history API (that is, it only returns the last visited time, not the actual visit time of an entry), a similar extension omits stale visits in older dates. Simply put, if you were to visit Facebook now, an entry of you visiting it yesterday will not show up. This extension instead chooses to show you all the links you have visited in a given date or from a query filter even if it has been visited recently.

Unfortunately, I am still in the midst of developing a workaround to show the real visit time of stale links.

TL;DR

• Open source;
• Ad-free;
• Tracker-free;
• Active development;
• Modern, predictable, and stable dependencies;
• Intuitive UI;
• High-performance;
• Fully featured.

This is the first, and last history page extension you will ever need.

Development

I have decided to release the extension after 64 commits 75 commits consisting of a name change, several changes to its dependencies, and countless iterations to both its design, and code architecture. In spite of all this, it is far from its final form. And there is still a long list of additions, and improvements that have yet to be made.

It is a work in progress.

It is built with heavy reliance on the latest, and most popular web libraries including React (Facebook’s UI library), and Fluxxor (a set of tools implementing the Flux architecture). It also relies on styles provided by Bootstrap v4 (Alpha).

You can examine the source code to see the symbiosis of these libraries, and the use of chrome.history API.

Unfortunately, I will not be documenting the development process in this post, but I will be saving it for another post, soon. Nevertheless, I would like to welcome contributions in any way, shape or form (e.g. pull requests, issues, feature requests, etc). You are most welcome to participate in the development process.

This project does not have an official communication channel, but I am generally easy to reach via Twitter, and IRC (join FyreChat #sandbox channel). I am also available via e-mail (using my contact form).

Post-publishing

It has just occurred to me, upon publishing my extension, that I have not included any option to delete a visit. I will be releasing a new version to address this as soon as possible.

Update v2.4.0 (23/09/15):

• You can now delete a visit from your history. For developers, the delete button can be found in the history actions component. Mouseover a visit to see the delete button;
• The visit’s full URL is now shown below its title;
• The results’ data are organised (i.e. positioned) through flexbox. From my knowledge, this should be supported in most Chrome browsers (31+).

Finally, there are several FAQs I would like to address before they are brought up:

1. In the results, why are some of the dates shown in full?

   As mentioned earlier, there are several constraints when using the chrome.history API. One of which is that it only returns the date / time you last visited a website (i.e. most recent access to a URL). If you have visited it before, it will still show up in the API results as a visit, but it will not show the actual date / time you visited it.

2. How does the search feature work?

   It is currently relying on the chrome.history.search API method to fetch the results. In the future, I will be implementing a client-side (i.e. JavaScript) search. The current search method should nevertheless be sufficient in most use cases.

3. How do I remove the date filter (i.e. show all)?

   Select the current date in the calendar. It can be toggled.

4. What is the logo supposed to be?

   

   It is a very unimaginative modification of the flux capacitor to resemble the letter X. The flux capacitor is the core component of a fictional time machine - called the DeLorean - from the movie Back to the Future. In the words of Dr. Emmet Brown, a fictional character (or rather, a mad scientist) in the movie, it is:

   What makes time travel possible.

   Coincidentally, Flux is also the backbone of this extension. It is the application architecture that I am using for the unidirectional propagation of data, and changes in the UI. Thus, I felt it was only fitting to reference the flux capacitor. After all, this extension is essentially a time machine for Chrome.

   In fact, the extension was named DeLorean for a while, until I decided to change it because I felt that it would not be an easy name for people to find (on Chrome Web Store) or remember. The current name seems to reflect its intent a lot better to those who have never watched Back to the Future.

• Session control: ACL-based authentication and authorization
• Globals: Setting [ REUSABLE ] defaults for your template (stylesheets, JavaScipts, variables…)

Core / base controller (globals)

We may for example create a core / base controller that would set layout.tpl as its default layout and assign a template variable to a string array of stylesheets or JavaScripts to import.

controllers/base.go:

type BaseController struct {
    // Embedding: "Inherit" beego.Controller
    beego.Controller
}

func (this *BaseController) Prepare() {
    // Overwrite beego.Controller.Layout (string)
    this.Layout = "layout.tpl"

    // beego.Controller.Data comprises of a map of template variables
    this.Data["HeadStyles"] = []string{
        "//cdn.jsdelivr.net/pure/0.5.0/pure-min.css",
        "//yui.yahooapis.com/pure/0.5.0/grids-responsive-min.css",
        "//fonts.googleapis.com/css?family=Roboto:400,500,300",
        "/static/css/base.css",
    }

    this.Data["HeadScripts"] = []string{
        "//cdn.jsdelivr.net/modernizr/2.8.3/modernizr.min.js",
    }
}

Any new struct embedding BaseController{} will now inherit its methods and variables (only Prepare() in this case) as well as those in the anonymous member beego.Controller{} as it is embedded in BaseController{} (refer to the first few lines). Unless the new struct sets its own Prepare() method, Beego will fallback to using the next defined Prepare() which in this case, belongs to BaseController{}. Our new struct will now have a Layout variable that is set to layout.tpl (overwriting beego.Controller{} default) and an array of styles and scripts in HeadStyles and HeadScripts template variable (set via Data) respectively, by default.

Fun fact: beego.Controller.Prepare() does not contain any logic.

This is useful for reducing redundancy in our controllers. Indeed, we do not have to define the same Layout in every controller, and we may, on a per controller method basis, add or remove styles and scripts from our template just by altering the HeadStyles and HeadScripts array. For example, assuming we have a layout…

views/layout.tpl:

<!doctype html>
<html class="no-js" lang="en">
    <head>
        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">

        <title>Beego App: {{.Title}}</title>
        <meta name="description" content="">
        <meta name="viewport" content="width=device-width, initial-scale=1">

        {{range .HeadStyles}}
            <link rel="stylesheet" href="{{.}}">
        {{end}}

        {{range .HeadScripts}}
            <script src="{{.}}"></script>
        {{end}}
    </head>

    <body>
        {{.LayoutContent}}
    </body>
</html>

And a new struct controller named HelloWorldController implementing BaseController{}.

controllers/helloworld.go:

type HelloWorldController struct {
    // Embedding: "Inherit" BaseController
    BaseController
}

func (this *HelloWorldController) Get() {
    // Set {{.Title}}
    this.Data["Title"] = "Hello World!"

    // TplNames is parsed into {{.LayoutContent}}
    this.TplNames = "hello_world.tpl"
}

Beego will automatically render (if the AutoRender config is enabled) hello_world.tpl AND layout.tpl. The contents of hello_world.tpl will be imported into the LayoutContent template variable [ in the curly braces ]. Additionally, {{range .HeadStyles}} and {{range .HeadScripts}} will loop through our string array of stylesheets and JavaScripts so that we can import them into our HTML page. Our HTML document title will be “Beego App: Hello World!” once successfully rendered.

Notice that in our HelloWorldController.Get() method we did not have to define what Layout is as it was already defined by HelloWorldController{} parent, the BaseController{}. Thus, when the Render() method is fired, it will be in the context of HelloWorldController{}. We can even include specific stylesheets and scripts specific for the HelloWorldController.Get() method by using Go’s append function on this.Data["HeadScripts"].

If we were to rewrite HelloWorldController{} to implement beego.Controller{} instead, Layout will not be defined as well as the other template variables we are using for our JavaScript and stylesheet imports. The resulting HTML output will simply be a parsed hello_world.tpl without layout.tpl.

You may visualise the inheritance of our controllers in the following manner:

1. beego.Controller
2. beego.Controller -> BaseController
3. beego.Controller -> BaseController -> HelloWorldController

By extending the original beego.Controller{} we may overwrite its methods and variables, and implement our own logic that will better cater to our needs. Best of all, we can abide by DRY (Do Not Repeat Yourself) principles.

Execute parent Prepare()

If we were to create a new Prepare() method in HelloWorldController{}, the Prepare() method in BaseController{} will no longer be fired (for reasons we have highlighted above - it is overwritten). We may still however, execute the “parent” method by calling the struct name directly (for anonymous members) or the field name. For example:

controllers/helloworld_with_parent.go:

func (this *HelloWorldController) Prepare() {
    this.BaseController.Prepare()

    // Do other stuff
}

Both HelloWorldController.Prepare() and BaseController.Prepare() will now be fired in that order.

Through this additional extension, we may not only maintain the logic and variables established in our parent controller, but extend them further to encompass new logic or variables for all methods in a controller. We may for a specific controller, validate a user session to see if they are logged in and redirect them away from it if they are not, and at the same time, we can still keep our parent variables which can be used to render the template to those who are logged in and validated.

As a final note, it is probably worth exploring Beego Godocs, Beego source code and WeTalk, a project made in Beego by… Beego to learn more about the ins and outs of the framework (not as well documented on the official website, probably due to the lack of English contributors). You can see Prepare() in action in Anna & Daphne’s admin control panel.

If you are running a website that requires a user-password-based authentication system there is a high chance you are probably handling the password poorly (at least in my books). Indeed, several e-commerce and e-banking websites are doing it wrong too. As a disclaimer, I am neither an expert in web security nor am I one in user experience. The following post is not targeted towards a layperson. I am merely synthesising a list of bad questionable password practices by web developers and they are based on personal observations (albeit, with some support from the web community).

Unnecessary requirements…

Maximum password length.

I can only identify six key reasons why any website would choose to set an upper bound limit on a user’s password:

1. The use of legacy systems and/or a legacy password hashing function;
2. Convention and/or a guideline set by a very naïve, higher authority;
3. To store the password in plaintext or encrypted plaintext (different from hashing) [to accommodate a database schema];
4. Developing from point 3: to prevent injection-based attacks;
5. Reduce likelihood of users forgetting?
6. To mitigate (D)DoS attacks.

I do not find reasons one to four reasonable at all. They are not valid excuses in this day and age.

Your authentication system should be “designed for failure”. With the increasing number of prominent database breaches, it is no longer logical (rather, it never was) to assume your users’ confidential data are not susceptible to compromise. As such, it is not logical to store passwords in plaintext or in an encrypted format that is either reversible or generated by a weak cryptographic hash function. You are exposing your users (particularly those who share their password across different websites) to risk in the event your users’ credentials are exposed to malicious individuals.

Reason 4 should not be an issue once you have password hashing in place as you are merely storing the hashed password, and thus, you should neither be passing any system-sensitive command to the database nor should you be validating the original password in plaintext. The length of a user-entered password will not affect the length of the hashed password, and hence, it will not affect the database schema (it will remain consistent).

Reason 5 should be accounted for via automated password recovery processes. Users should be given the freedom to set a password of any length (even if they are more likely to forget them, but that is not for you to judge) inasmuch as it is not detrimental to your website (reason 6). In my opinion, it is bad UX to set such hard limit.

Reason 6 is a machine problem, not a user one, and they should not be punished for it. The machine should be configured to deal with DoS attacks and to drop adverse request handlers (e.g. via request thresholds, filters etc). DDoS attacks may be mitigated by building the website to deal with CSRF (e.g. via captchas, hidden key, etc). Admittedly, dealing with DDoS attacks are far more complex, but by preventing remote requests you are removing one source of attack and you will increase the complexity for the attacker. Worst-case scenario, it is justifiable to set a generous upper bound limit.

We set a lower bound (minimum) limit for passwords because shorter passwords are easier to guess and/or brute force (for humans and machines alike). Thus, it is only logical to allow for longer passwords with higher entropy.

Passwords with special characters.

Websites that do not allow special characters in passwords seem to imply the same reasons postulated above. Indeed, this practice strongly implies to me that the web developer is concerned with the content of the password as it may be malicious (reason 4), and this makes me very concerned as well.

As I have explained already, if the password is hashed this should not be a concern at all. You are not passing system-sensitive commands. You are passing gibberish. If it is a concern, then chances are it is probably stored in plaintext or in a format that is reversible (and potentially harmful for the system in the web developer’s perspective). This should raise some serious red flags.

Instead, special characters should be encouraged. They add complexity to the resulting hashed password thereby increasing the time it will take to crack the password via hardware and technique-based attacks (e.g. dictionary, brute force, etc). On the contrary to XKCD-936, it is no longer secure to set a purely alphanumeric password, let alone one that is composed of words. Granted, it does increase the entropy of your password and reduces the likelihood of someone guessing it. The concern arises however, from the assumption [that I have previously made] that if the hash of your users’ password are stolen, they are vulnerable to being cracked by dictionary-based attacks.

Freedom and predictability.

Imposing machine requirements on passwords is fundamentally bad UX and bad security design.

Users should be given as many opportunities as possible to safeguard their own accounts and identities. Web developers should accommodate for this, and not the other way around. A restriction-less password is the first step in doing so. It will grant users the freedom [and arguably, the responsibility] to ensure the security of their own account. Users with a greater affinity towards higher quality passwords should not be restrained by petty limits on the length and/or characters. Other [strongly encouraged] steps may be taken including password expiration, two-factor authentication, limits on failed authentication attempts (lockout), IP address restrictions, SSL etc.

It is also a bad security design as it helps attackers by reducing the range of possible passwords. For example, an attacker needs to only test for alphanumeric passwords if a website is set to allow alphanumeric passwords only. There is no need to account for other characters. Thus, a lack of password definition / rules will provide another variable for the attacker to account for thereby increasing the complexity (or rather, broadening the assumptions).

A note on hashes.

Cryptographic hash functions generally return a fixed-length hash value. Consequently, there is a chance that a hash of one string may be the hash of another string. This phenomenon is known as a hash collision, and while the possibility exists, some cryptographic hash function are more resistant to it than others (the cost of discovering these collisions, e.g. via birthday attacks, are much higher). Consequently, there may be some diminishing returns beyond some password length depending on the strength of the cryptographic hash function used.

Password strength checkers and minimum score.

Password strength checkers rely on a custom security criteria which more often than not, is flawed. They are commonly calculated by measuring the entropy of the password or by comparing it to a set of regular expressions. High scores may be achieved by lengthier passwords (such as those composed purely of random words), but the overall quality of the passwords may not necessarily be high, for reasons explained above (they may even fall in a list of common passwords or patterns).

For someone who is not familiar to the concept of passwords such a mechanism would be useful for guiding the user towards a more complex password with greater entropy, and hence, theoretically greater security. Enforcing a score-based restriction is nevertheless bad UX (it forces users to behave like machines which may also give a false sense of security), and in some cases, it may be a bad security design if it forces users to conform to a certain pattern of password (e.g. start with capitals, include X or Y, etc).

Indeed, the findings in a research into the NIST model of password entropy (a heavily recommended scheme for estimating the entropy of human-selected passwords) showed that:

…the NIST model of password entropy does not match up with real world password usage or password cracking attacks. If that wasn’t controversial enough, we then made the even more substantial claim that the current use of Shannon Entropy to model the security provided by human generated passwords at best provides no actionable information to the defender. At worse, it leads to a defender having an overly optimistic view of the security provided by their password creation policies while at the same time resulting in overly burdensome requirements for the end users.

Password Account recovery.

Assuming most “forgotten password” functionality relies on a user’s e-mail address, then no credentials (the password in particular) should be sent to the user via e-mail, regardless of whether it is the user’s original password or if it is a randomly generated password.

Indeed, for security reasons, under no circumstances should you have access to the user’s original password. As I have previously mentioned, passwords should not be stored in plaintext or in a format that is easily reversible. It must be hashed using a reliable cryptographic hash function. Any website that sends you your password is clearly not handling your data securely, and it is probably not trustworthy.

It is also not advisable to reset the user’s password. By setting a randomly generated password without the user’s prior consent you are doing the following:

1. Diminishing users’ freedom and control over their data.
2. Potentially jeopardizing users’ security should they choose to write it down (due to its complexity) or should someone else see the password in their e-mail account.
3. Developing from the previous points: it may increase the complexity (adds more steps) of the recovery process as the user is likely to change the automatically set password upon authentication.

The user should be given the freedom to set a new password immediately. This is probably how the user wants it to be anyway.

Measures should also be taken to secure the account recovery interface (e.g. via unique tokens, expiration, throttling, etc), but it is not for the purpose of this article to discuss. Refer to the definitive guide to form based website authentication for more information.

Password Data validation.

Users should be informed about the validation requirements before the validation process occurs, not after. It will save the user’s time and it is less frustrating that way. They should not be expected to predict a system’s design only to be punished for not being able to do so. Don Norman’s “Error Messages Are Evil” summarises this problem succinctly:

A truly collaborative system would tell me the requirements before I did the work. If there are special ways you want stuff entered, tell me before I enter it, not afterwards. How many times must we endure the indignity of typing in a long string only to be told afterwards that it doesn’t fit the machine’s whims (more accurately, doesn’t fit the whims of the programmer)?

Restrictions may vary from one website to another. Thus, it should be made explicitly clear what would constitute an “acceptable password” (e.g. special characters, uppercase/lowercase, numbers, etc) if you do intend on setting restrictions. Take French Connection United Kingdom (FCUK) online registration form for example:

The developers only made clear the lower bound limits, but made no attempt at informing me of the specific upper bound limits (even after the form has been validated). Please do not force your users into a guessing game. It took me several attempts before I realised that the character limit was 12 and that I could not use special characters. By making the lower bound limits obvious instead of the upper bound limits, you are only encouraging users to go for the bare minimum (to avoid your otherwise annoyingly vague form rules and error messages).

Password masking.

Jakob Nielsen’s “Stop Password Masking” thoroughly summarises the problems with password masking:

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures.

…there’s usually nobody looking over your shoulder when you log in to a website. It’s just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

It is a legacy design ingrained by browser vendors. We have adhered to it because it is simple and conventional. In reality, the lack of feedback makes us more prone to errors or bad password practices (e.g. simple passwords, copy-pasting, etc), and the former is exemplified by the need for an extra password field as confirmation (further complicating registration processes).

Nielsen instead recommends offering users a checkbox to have their password masked for high-risk locations (internet cafes) or high-risk applications (bank accounts). Indeed, Microsoft’s Internet Explorer 10 have included a small icon for password fields that will allow users to view their password in plaintext.

If you have never heard of Nielsen, he is an acclaimed web usability consultant. He is known for publishing his usability heuristics in 1994. Currently, his heuristics are perhaps the most-used heuristics for user interface design. It is a set of guidelines that may be used to identify potential usability problems in a design (albeit, not strictly). You can run a heuristic evaluation on your own website through UX Check (a Chrome extension).

Do what we can with what we got.

Password-based authentication systems are inherently flawed, but they are the best we got with regards to ease of deployment, security, and usability (although projects like Mozilla’s Persona are trying to challenge this). We should not make such a system worse than it already is. We should work towards perfecting it while striking a balance between security and usability.

Ultimately, code is law and the web developer is the legislator. As the legislator, you are responsible for the behaviour and the security of your users. You can make their web experience pleasant or unpleasant. You can do whatever you can to guarantee their security and the security of the information they provide you with, or you can just neglect them and deal with a PR sh*tstorm (for lack of a better word) when your complacency is exposed.

The decision is yours to make.

An ongoing discourse.

Preventing errors from occurring is always the best course of action, but when that is not a possibility, ensure it is human, helpful, humorous and humble.

Update (23/05/2014): Interestingly enough, I wrote this article (and published it privately) before eBay suffered a data breach recently. Impeccable timing.

Update (30/07/2014): There is a Tumblr dedicated towards shaming websites storing passwords in plaintext. Unlike the password hall of shame linked earlier in this article, PlainTextOffenders.com is new and kept more up-to-date with submissions from the community. I strongly recommend reading the Developers FAQ even though some of the points has already been highlighted in this article (albeit, not as succinctly).

Update (14/08/2014): Jeff Atwood from Coding Horror (and the co-founder of Stack Overflow / Stack Exchange) wrote a post in 2007 targeted towards developers “storing passwords incorrectly”. It is worth a read albeit being dated.

Update (04/11/2014): Is it time for Passwordless Authentication? Researchers at Mozilla proposed an innovative approach towards login systems which relies on authentication tokens sent to the users’ e-mail address or through SMS. Thoughts?

Update (30/01/2015): Duncan of Vents that Look Like Faces discussed the prospects of piggybacking on existing  SSH technology and using it as an option for web sign-in. A demo was also developed as a proof-of-concept and assessments were made based on usability, deployability and security considerations (part of a scoring framework advanced in The Quest to Replace Passwords by Joseph Bonneau, Cormac Herley, Paul C. van Oorschot and Frank Stajano). These considerations allows us to consider the intricacies of attempts at replacing the conventional password system, and it allows us to contextualise the longevity as well as the prevalence of such system design. Through this framework we can weigh the relative advantages and disadvantages of alternative modes of login.

Update (11/09/2015): Anthony, the editor-in-chief of UX Movement, provides a case for removing the password confirmation field, and forced password masking as it is likely to lower conversion rate. Similarly, he recommends that a “show password toggle” should instead be offered.

By giving users control over their password input, you give them the peace of mind to complete your form.

Update (08/10/2015): Password Requirements Shaming is yet another Tumblr dedicated towards shaming websites with ridiculous password requirements / questionable management practices. Commentary is included for most of the offending sites.

Update (21/11/2015): In Patronizing Passwords, Joel writes:

We have to remember that at the end of the day, users are more than just a weak point of security in our systems. Our services exist for our users, not despite them. I like to think there are ways to get people to use strong passwords without forcing their hands and negatively affecting their experience using our products.

Update (01/12/2015): In The Password Paradox, the author mirrors the aforementioned arguments about password masking:

Clear text passwords do increase usability, but don’t force the change on existing users. Password masking is best offered as an option to maintain user trust in the site.

lukemichael5 asked:

Hank, Is there any psychological or biological reason for why people stand in the shower for a long time when thinking? Does the running water provide any mental relief? Could there be an evolutionary reason why? Have I asked too many questions for you to answer? (Probably)

edwardspoonhands answered:

I honestly think it’s because every other moment of the day is filled up with THING TO DO! ADVERTISEMENT! SMARTPHONE! STIMULUS! GET IN THE CAR! DO THING! STOP STOPPING! START STARTING! NO THINKY! THINKY BAD! GO GO SPEND WATCH DO MOVE GO! The shower is like, the last place where you can feel ok about just standing there.

I’m going to take a shot at this question since I’ve been pondering over it for some time, looking for the right [scientific] answer(s). Based on what I know, I think it is a combination of both psychological and biological reasons: cognitive neuroscience (perhaps some elements of behavioural psychology as well).

Apologies for my naive response, as a disclaimer I am not an expert so take what I say with a grain of salt.

It is biology…

Firstly, the “thinking” part of a long shower I believe is - as Hank stated - a result of a bombardment of stimuli from our sensory organs in our everyday lives. Obviously, our central nervous system (CNS) isn’t capable of responding to each and every one of the stimuli and consequently, we have developed (un)conscious filtering mechanisms - see selective perception. In the shower however, we aren’t subjected to this bombardment (or at least my showers aren’t) that has been exacerbated by the internet and social media in particular over the past couple of years. I suppose this is why we can be in a state of Zen and think better, inevitably losing track of time.

As the saying goes, a hot shower helps takes your mind off things (escape from reality?).

I don’t think that answers the question really well though.

If we unpack the first answer further, I suppose it is because showers are essentially hydrotherapy. It is a natural sedative due to the way our body responds to things like the temperature and the pressure exerted by the water (the hydrostatic effect of water generates a sort of “massage-like feeling”). These sensations are communicated through our nerves, to our CNS, and to the rest of our body - stimulating and invigorating various bodily activities, e.g. improving our blood circulation which may be a contributing factor to our improved ability to think.

Indeed, a study showed that “a moderately hot shower, could have a ‘crowding out’ effect on pathological processes within the mesolimbic system”. Simply put, [moderately hot] water does provide mental and physical relief by suppressing pain-related neurotransmission / negative stimuli. Cold water however, may depress activity of the frontal cortex (sedative effect). See pain modulations and mechanisms.

It is no wonder why we may often find showers so relaxing. It is therapeutic.

But, psychology!

I figured I should include a section about psychology as well because a. I am going to assume there will be anomalies and if so, psychology can account for the differences; and b. I like psychology.

Firstly, our behaviour and appreciation of standing “in the shower for a long time when thinking” may have been developed over time through psychological conditioning. The law of effect states that any behavior that has good consequences will tend to be repeated, and any behavior that has bad consequences will tend to be avoided. This is known as operant conditioning (learning based on the consequences of previous occurrences of the behaviour).

As I have explained earlier, the consequences of long showers may be the alleviation of stress (negative reinforcement) and/or the enhanced ability to think (positive reinforcement). If you find this desirable, the frequency of the behaviour being repeated will be increased. Think of it this way, you’re more likely to behave in class if it means getting some sort of reward from your teacher or reducing the likelihood of a punishment. In this case, you may resort to a [long] shower if it helps you escape all the stress caused by the stimuli you have received in your surroundings.

Before I conclude, I think it is worth mentioning the drive-reduction theory despite its pitfalls. The theory states that “humans are motivated to reduce the state of tension caused when certain biological needs are not satisfied”. Basically, we are motivated / driven to behave in certain ways by the active need to maintain a certain state of balance or equilibrium (homeostasis). Building on what I’ve already mentioned in the last paragraph, the reduction of the drive acts as a reinforcement for that behaviour. I may be overextending this theory for this question, but a long shower may satisfy our need to think or relax, and its success / reliability in doing so will reinforce our craving for it.

With that being said, will you stand in the shower for a long time when thinking if it was extremely cold or hot?

Suum cuique pulchrum est. To each his own is beautiful.

There may be an evolutionary explanation, but it is too fluffy and subject to a lot of criticisms.

To close, biology and psychology works hand in hand to explain the phenomenon that is showers and thinking.

Perhaps this can also explain why you think a lot when you are about to sleep or when you meditate / partake in yoga, Tai chi, etc.

I was tempted to say, science and psychology, but that would imply psychology is not a science which may be offensive. That is another debate for another day…

TL;DR: Read everything from the beginning.

Towards the end of 2013, I decided that I was going to begin blogging more often (or at least try to) and that I was going to do so on my existing WordPress platform. It was not a decision made as part of my New Year’s resolution for 2014 and indeed, it may never materialise.

I nevertheless took the first steps by removing all my old and unimportant posts as they felt like a distraction and dead weight. For the old and slightly more important posts (the ones that are bringing me traffic) I decided to update them (four actually) and to tag them as Legacy. I worked sporadically over a period of one month - as I have been busy - before I was finally satisfied to make a post about it today.

The legacy.

In computing, the term legacy is used to denote software or hardware that has been superseded but is difficult to replace because of its wide use [Oxford Dictionary]. The older versions of Internet Explorer for example, were considered legacy web browsers for some time (and I am not too sure if it is still the case) until there were major strides in the online community towards pushing for more modern alternatives including Google Chrome and Firefox - hence, their increasing market share.

I have marked four of my web design / development related posts as legacy as I do not intend on updating them anymore. Thus, the contents of the posts - be it technical or purely descriptive - may or may not be relevant today or in the near future. The WordPress code I have written for example, may no longer be usable in the near future (it should still be at the time of this post) due to WordPress rapid development cycle. Furthermore, my web design / development bookmarks may no longer be accessible or useful due to the quick evolution of technologies and of trends in the web arena.

Perhaps one day I will remove them, but for now I am keeping them as I believe it still adds some value to my barren website (and hopefully to the web community which I owe a lot to).

The unimportant.

If I recall correctly, I had previously mentioned somewhere that I was unsure of what I should do with my older posts and that I felt they should be kept as they served almost like a time capsule and an insight to my past. Well, I decided to remove them, but only from the public. I still have a backup with me, but I highly doubt I will ever go back through it. Indeed, I could not even be bothered to look at my previous two posts before I decided to write this.

They are a burden to keep and would give a misconception of who I am today. Maybe I am being a bit too pessimistic, but I am convinced humans are naturally judgmental by nature (I do care now), be it conscious or unconscious, we all judge and build preconceived notions of others to aid our everyday interaction. I intend on keeping this website professional unlike its past.

The WordPress.

The recent WordPress 3.8 update (“Parker”) reminded me of why I had started with it instead of all the other solutions available. Simply, it is innovative, open and flexible. A huge time-saver as well! If there is any reasons why I am not comfortable blogging I do not think it has anything to do with the platform anymore. I was probably making excuses before (Medium is still pretty cool though). The new admin UI changes on WordPress are nevertheless absolutely stunning. Perhaps once I have developed a custom theme (not that there is anything wrong with the existing one) and switched over to Markdown - which should hopefully be included in JetPack soon - it will start to feel more like home.

Finally, going rogue.

Besides Twitter and YouTube, I just do not feel social anymore. Both online and offline. I have tried to remove myself from all of it, or at least remove my identity. I have deleted my Tumblr in the process and made private my Twitter account (to hide it from the prying eyes of a particular person, or people, I am not too sure…).

If there is anything I would like to dedicate more time to it will probably be the open source community, particularly in the web sector. Thus, I have tried to be more active on GitHub and like my legacy posts I have decided to update my old repositories as well.

Nothing relieves my stress more than coding. There are times when it can get frustrating, but I always feel like I am more in control. In our world however, it feels like there are things that we can not control and circumstances that we can not alter. If my code is not functioning the way it should, I know it is because of my incompetency and I know, I can fix it with enough persistence. It is also extremely gratifying to design and build whatever you like or whatever comes to mind with simply a computer and an internet connection.

Maybe that is why I do not feel social anymore. I do not feel in control of social situations and they simply add to my stress.

Regardless, the web is awesome.

That is all for now.

Happy new year.

A part of me however, has begun considering the possibility that I may not have come to terms with the observed fact that anything non-mathematical is incapable of achieving perfection (thanks Plato, really). I feel it is crucial for any writing or social platform to emulate the sort of environment we experience in real life to provide the necessary psychological cues and to hence, create a genuine experience; a sense of home. For example, I have recently sought refuge at Medium and have attempted to publish my first writing but to no avail. Being the amour-propre (I use this term very loosely) man who I am, Medium’s lack of author attribution (and rights) is unappealing to me and while it succeeds in creating a “social experience” I can call home, this home is definitely not mine. It is not one which I can call fyianlai.com, that is for sure. Meanwhile, my existing WordPress web site is one which I can call fyianlai.com, but it is not one which can emulate the serenity that I experience in a distraction-free, warm shower or in my cosy bed - at least not to the extent at which Medium achieves it. Obviously developing my own platform is the only advisable option at this point, but that brings me back to the original question problem, how do I achieve the utopian platform?

I have been stuck at a creative and to some extent, a logical block these past few days while trying to brainstorm ideas for my web site’s design and its features. Should I pursue the “static site” approach or should I consider the “dynamic” approach instead? How should it look like and how do I design it so that it does not seem like a complete rip-off from another site? Building a new home is not easy. There are a lot of considerations and re-branding is definitely one of them. One consideration leads to another. Indeed, if re-branding is the key objective then the technologies utilised would say a lot about you as a web developer, and particularly your awareness about the current trends. If I am incapable of achieving the “perfect platform”, how certain can I be that simply moving out of WordPress would encourage me to be more “social” in my internet home?

I am uncertain if my dilemma lies in a failure to emulate an experience, or if its philosophically and psychologically related. The latter being my absurd pursuit for perfection and a simultaneous recognition of the lack of feasibility of such task. For example, I would commit an unnecessary amount of time to formulate what I deem the “perfect essay” that would encompass all relevant sources I have acquired only to resent it the moment I discover flaws and imperfections. Based on the aforementioned assessment and example, I suppose my passivity can only be explained as an equilibrium, and specifically, a mental stalemate whereby doing nothing will achieve less psychological conflict. I find myself difficult to analyse sometimes so my only solution for now is to search and destroy all possible roots of the problem. Indeed, I am writing this post to address the latter problem, hoping that I would eventually condition myself into accepting and ignoring this cognitive dissonance. After all, practice makes perfect.

It is this process of self-discovery that really fascinates me. After all, humans are dynamic in nature and unlike mathematics, we can not achieve the same level of objectivity, but that is something I will save for and discuss in a future post.

Seeing then that truth consisteth in the right ordering of names in our affirmations, a man that seeketh precise truth had need to remember what every name he uses stands for, and to place it accordingly; or else he will find himself entangled in words, as a bird in lime twigs; the more he struggles, the more belimed. And therefore in geometry (which is the only science that it hath pleased God hitherto to bestow on mankind), men begin at settling the significations of their words; which settling of significations, they call definitions, and place them in the beginning of their reckoning.

- Hobbes, Leviathan

A recurring process of self-reflection has often made me dissatisfied with my past behaviour and even my past writings. The process is further catalysed by my concerns that as a native English speaker and a student in a somewhat prestigious university, it is necessary for me to be well-versed in the English language and articulative. After all, I am currently pursuing a course that is essay-based in its entirety. I am unfortunately, terrible at phrasing complex sentences according to many of my past English teachers and their criticisms in the past have to some extent, diminished my confidence in publicising any of my writings. I am nevertheless, grateful for their guidance.

My grasp of language however, is not the only reason why and I feel I am often constrained by demand characteristics. For those who know me personally, I can be quite critical on certain issues and I feel my opinions may be strongly opposed or even criticised. I honestly dislike making mistakes and I do not like pre-conceptions of me based around mere words.

Finally, as a “self-proclaimed web developer and designer”, I have a rather bad ego which makes me reconsider the way I have presented my posts, from the little things like the formatting to things like the theme and colour scheme.

I have a brain bug that is making conscious reconsiderations before I make a post and after I make one. It is killing me because I am unable to express myself and for some reason I think going on a hiatus or deleting myself off the internet is the only way to solve it.

It seems as though, the more I read what I have written or even work on something I have created (e.g. a web application), the more I find flaws with it and dislike it entirely. I guess I can never be satisfied.

It may seem quite ironic that I am finally expressing myself through this post. I wished I had this figured out before I massacred my past writings. Simply put: I don’t care. Welcome to my website. A home for my thoughts. I am tired of being stuck in an online identity crisis that is constrained by my Schizophrenic tendencies. Humans are instinctively judgemental and I should not have let that defined who I am. If anything, I should have kept my old posts and continued posting as it would have shown an evolution of myself, as an individual - a timecapsule of me. I am not politically correct and neither is anyone if you are speaking in terms of social constructivism. If I am empirically incorrect, I will learn from my mistakes. I am not writing an academic paper so I shouldn’t even be concerned about my linguistic abilities, even so, most academic writings I have read are poorly articulated.

In short, I have conquered my fear. I do not know why or how but I suppose several experiences in the past have made me realise that we are all the same, simply looking to stand out from a pool of tiny units in a vast cosmos just so we feel different from all the other units for a while. Here is the legitimate me. I am happy in my own way and I don’t care even if this post is redundant. I am just going to keep moving forward.

For a full list of content-curation web sites and users you can check out my Twitter list here. I have discontinued my “web dev/design bookmark” series of posts in favour of a unified collection of bookmarks in Evernote. You can check that out here - I have not included some of the links below.

I originally created this blog post along with part 1 because I wanted to curate a list of useful links that I could come back to in the future, especially in cases where I vaguely remember where a certain resource or an article was from. There are a lot of cool stuff on the internet and sometimes you do not want to lose track of it.

The web design and development community is vast and fascinating. If you are part of it, hopefully you would have figured that out by now and if not, you need only to explore all the links in this post to understand what I mean.

I apologise in advance if any of the links below no longer work. I will not keep the following post updated anymore as I have previously mentioned. I hope you will nevertheless find this post of some use.

HTML / CSS / JS

• Pushing Updates to the Web Page with HTML5 Server-Sent Events
• jQuery & CSS3 Tooltips
• WebKit Marquee CSS: Bringin’ Sexy Back
• Interesting -webkit CSS Properties
• Sass vs. LESS vs. Stylus: Preprocessor Shootout
• Vendor prefixes are not developer-friendly
• Paul Irish: * { box-sizing: border-box } FTW (Solving Width & Padding Problems)
• More Noticeable HTML Bookmarks (jQuery)
• Fontomas – A tool that helps to combine Iconic webfonts
• Login and Registration Form With HTML5 and CSS3
• Using Modernizr to detect HTML5 features and provide fallbacks
• Maintaining CSS Style States using “Infinite” Transition Delays
• jqFloat.js – A Floating Effect with jQuery!

Frameworks / Libraries

• Twitter Bootstrap For Wordpress
• basket.js - A simple (proof-of-concept) script loader that caches scripts with localStorage
• Chico UI - A free and open source collection of easy-to-use web tools for developers and designers
• Skeleton - A Beautiful Boilerplate for Responsive, Mobile-Friendly Development
• Dexy - “The Most Powerful, Flexible Documentation Tool Ever”
• noty – Easily create alert, success, error and confirmation messages

Inspiration

• Building a Great Web Design Portfolio – 10 Best Tips & Examples 
• Five Alternative Methods for Typography Inspiration
• 18 Super Quick Web Typography Tips for Newbies

Free Resources

• Simple Tape - Free Minimalist HTML Site Template 
• Stumblr - Tumblr Style Wordpress Theme (Micro Blog)
• Liquid, Fluid and Elastic Layout Templates, Tools and Frameworks
• Free download: “Inspire” Backend Admin Template (PSD)
• Origin: Free Wordpress Theme

Optimization / Testing

• Website Speed Part 4: PHP Programming for Speed
• Resizer - A responsive design bookmarklet
• Why Inlining Everything Is NOT The Answer
• Dirty Markup – Tidy and beautify your HTML, CSS & JS code
• Kraken Web Optimizer - Online Optimization Tool
• TypedJS - Sanity Check Your JavaScript

Others

• More Resources, Tutorials & Freebies (Speckyboy Weekly 06/03)
• 50 Time Saving Photoshop Actions To Boost Your Images
• Top Non-Destructive Photoshop Techniques
• PHP 5.4 is Here! What You Must Know
• Useful WordPress Tools, Themes And Plugins
• How to Prepare for The High-Resolution Web

For a full list of content-curation web sites and users you can check out my Twitter list here. I have discontinued my “web dev/design bookmark” series of posts in favour of a unified collection of bookmarks in Evernote. You can check that out here - I have not included some of the links below.

I originally created this blog post along with part 2 because I wanted to curate a list of useful links that I could come back to in the future, especially in cases where I vaguely remember where a certain resource or an article was from. There are a lot of cool stuff on the internet and sometimes you do not want to lose track of it.

The web design and development community is vast and fascinating. If you are part of it, hopefully you would have figured that out by now and if not, you need only to explore all the links in this post to understand what I mean.

I apologise in advance if any of the links below no longer work. I will not keep the following post updated anymore as I have previously mentioned. I hope you will nevertheless find this post of some use.

HTML / CSS / JS

• How to Create CSS3 Paper Curls Without Images
• Different CSS3 Box Shadows Effects
• Orman Clark’s Chunky 3D Web Buttons: The CSS3 Version
• Learn jQuery In 30 Days
• HTML5 Canvas Tutorials
• HTML5 Please - Use the new and shiny responsibly
• Flared Borders With CSS
• How to Build a Stylish CSS3 Search Box
• CSS Reference
• Interactive Typography Effects With HTML5
• Creative CSS3 Animation Menus
• CSS3 Ribbon Builder
• Bear CSS - Generate CSS Based On Your HTML
• Fun With HTML5 Forms
• Video Re-Captcha
• MotionCAPTCHA - Stop Spam, Draw Shapes

Frameworks / Libraries

• Discover Facebook’s developer tools
• PHP Fat Free Framework (F3)
• Bootstrap - HTML/CSS Framework (by Twitter)
• Hojan.js - 2.5k  JS Templating Engine (by Twitter)
• Microjs: Fantastic Micro-Frameworks andMicro-Libraries for Fun and Profit!
• HTML5 Boilerplate
• Initializr - Start A HTML5 Project In 15 Seconds
• Modernizr - Feature Detection
• YepNope.JS - ASYNC Conditional Resource Loader
• CDN.JS - CDN For Popular JS Libraries
• Sharrre - A plugin for sharing buttons
• jQuip - “jQuery In Parts”

Inspiration

• 16 Best Web Design Galleries for Inspiration
• 33 Kick-Ass Websites for Your Inspiration
• 20 Magazine Layout Designs for Inspiration
• 32 Inspiring Examples of Amazing Layout and Typography

Free Resources

• 50 Stunning Pixel Perfect PSD Freebies
• 50+ PSD UI Web design elements
• 35+ Icon Packs For Web Designers (That Don’t Suck!)
• 20 More Fresh & Free Fonts for Beautiful Headlines
• FAMFAMFAM Icons
• Entypo - 100+ carefully crafted pictograms
• Heydings Icon - A Free @font-face Icon Set

Optimization

• Give Your Site A Health Check (Infographic)
• Microcaching: Speed your app up 250x with no new code
• Optimizely: A/B Testing

Others

• Tips for Creating a Magazine Layout in InDesign
• Your Brain On CSS - CSS 3D Demo
• The Reality of HTML5 Game Development and making money from it
• Useful PHP Snippets & More
• About normalize.css
• Taking Advantage of HTML5 and CSS3 with Modernizr

WordPress provides developers with a class of functions to manipulate the database and this is particularly useful for custom plugins and/or themes. Developers may interface - create, read, write and/or delete data - with the WordPress database via the global $wpdb object; however, to interact with another database (an external/secondary one) a new instantiation of the wpdb class is required. In WordPress’ codex, hyperdb is recommended as the solution “for extremely complicated setups with many databases”. If however, you are not too keen on using someone else’s plugin it is pretty simple to create your own custom database object using the wpdb class.

Here is a gist of how you may do so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
<?php
define('DB_HOST', '127.0.0.1');
define('DB_USER', 'root');
define('DB_PASS', 'password');
define('DB_NAME', 'school');

class CustomDatabase
{
    private $db;

    public function __construct() {
        // Connect To Database
        try {
            $this->db = new wpdb(DB_USER, DB_PASS, DB_NAME, DB_HOST);
            $this->db->show_errors(); // Debug
        } catch (Exception $e) {    // Database Error
            echo $e->getMessage();
        }
    }

    // Example Query -- Count Students
    public function count_users() {
        return $this->db->get_var("SELECT COUNT(*) FROM `students`;--");
    }

    // Example Query #2 -- Update Student Name
    public function update_student_id($student_id, $student_name) {
        return $this->db->update(
            'students',
            array('student_name' => $student_name),
            array('student_id' => $student_id),
            array('%s'), array('%d')
        );
    }
}
$Custom_DB = new CustomDatabase;
?>

Explain it to me?

The example in the gist above demonstrates how you can use the wpdb class provided by WordPress to communicate with an external database with entirely different database credentials (host, username, password and database name) as evident from line 2 to 5. In the example above, we are working with a database containing data of students in a school.

The CustomDatabase class seen above begins by instantiating the wpdb class into $this->db object as seen by the class constructor (line 11 to 19). A connection to the external database is stored in the object and it will not interfere with your WordPress database connection (which is likely if you were to connect using conventional PHP MySQL functions). Unlike the $wpdb global object however, $this->db is only accessible by the class itself (hence, the private declaration) and it is not publicly accessible (unless you make it so). Furthermore, $wpdb is only capable of interacting with the WordPress database as I have previously mentioned.

Using the custom instantiation of wpdb (stored in $this->wpdb) we can then manipulate data from our external database as seen on line 21 to 34. The count_users() function will return the total number of students in our students table of our external database. The update_student_id() function will update the students table by changing the name of a student with a specified student ID. As $this->wpdb is an object instantiation of the wpdb class, you may use any of its methods (refer to the WordPress Codex to find out more about the methods you may use along with their respective arguments/parameters).

You may use the described functions above by calling $Custom_DB->count_users(). The try-catch statement in the example is not necessary, but you should include a fallback / a mechanism to deal with failed database connections as it may interfere with your application.

And we’re done.

There is always a learning curve involved when working with new plugins, libraries, frameworks, etc. In the case of WordPress, it is unfortunately pretty steep in my honest opinion. The WordPress Codex is incomplete and in several occasions, provide close to no real world example that is accompanied by in-depth explanation. Fortunately for us developers, there are several websites and communities committed to providing what the WordPress Codex lacks (The Tuts+ Network and CSS-Tricks just to name a few).

Don’t get me wrong.

The WordPress Codex is not entirely flawed nor should it be considered useless. It succeeds in many areas (particularly on articles that are featured on its home page). It is merely ineffective. Indeed, it fails to compensate for various types of learning preferences. Those who are capable of deciphering and experimenting with the ins and outs of its simplicity will excel best. It is definitely not easy to get to grips with initially, but with dozens of resources out there (tutorials, frameworks, plugins, etc) and a strong support network (e.g. Stack Overflow), I suppose there is not any real need for the Codex to be heavily revamped and the time saved may be invested in other areas such as improving the overall code base, which the developers are doing a fantastic job at.

As always, feedback and opinions are welcomed.