What are the expectations of a UI architect?

First, you are designing the user experience (UE), not just a UI. You want to know your audience; expert, in-house, public, or a combination. For the public, you want to understand your target audience; perhaps some demographics like age and education. What is the goal of the site/app?

Second, designing a UI does not happen in a vacuum. It needs to interface not only with front end aspects like OS, browser, etc. but also with potential items like databases, external inputs(location, movement, etc) You need to be aware of those parameters so as to avoid creating a disaster for the team behind you. You are a member of a team!

Third, you need to understand what can be (reasonably) done within the architecture you are using. This is very much a balance issue, i.e. is it worth the development time vs the return or would something simpler fit the bill just as well.

Fourth, you need to interface with the client/ end users. You are both a translator and a communicator between the user and the programmers. To the third item above, the client may give you a list of things but they may not be willing to invest the money or potential launch delay to implement one or more of those items.

Unfortunately, I see more poorly thought out UI’s today than previously. For example, I critiqued a website recently that had fantastic programming with all the latest widgets. Very modern and geared toward twenty-somethings. The problem is their target audience was 45–65; a group that probably closed the tab within 15 seconds. Or seeing an expert POS system where the employee had about 50 mouse clicks to complete one screen. Had it been keyboard-driven, it would have taken about 1/3 the time.

Those were two bad user experiences where the architect just forgot the mission and didn’t consider the target and goal. Or maybe failed to ride herd on the team. Riding herd is a good skill; it isn’t so much that every member of the herd has to be in an exact position, but the herd needs to keep moving in the right direction and keep those strays closer.

I love software.

The more complex the better! What makes other programmers turn away in disgust is simply fascinating to me.

What interests me about technology is its significance as an artifact of human thought.

I’m really into the human factors of complexity theory. I’m really into systems thinking. I’m really into organizational behavior and cognitive biases. Code is interesting to me not because it is good or bad, elegant, or abstract, but because it is a manifestation of how people see the world, what assumptions they make, what associations they create.

Data Structures for Frontend Software Engineers

It’s more than just style…

Now, in addition to having an aesthetic understanding of HTML and CSS, Frontend Engineers are expected to master JavaScript as well. As datastores on the client become “replicas” of databases on the server, intimate knowledge of idiomatic data structures becomes pivotal. In fact, an engineer’s level of experience can be inferred from his or her ability to distinguish when and why to use a particular data structure.

Bad programmers worry about the code. Good programmers worry about data structures and their relationships. — Linus Torvalds, Creator of Linux and Git

At a high level, there are basically three types of data structures. Stacks and Queues are array-like structures that differ only in how items are inserted and removed. Linked ListsTrees, and Graphs are structures with nodes that keep references to other nodes. Hash Tables depend on hash functions to save and locate data.

In terms of complexity, Stacks and Queues are the simplest and can be constructed from Linked ListsTrees and Graphs are the most complex because they extend the concept of a linked list. Hash Tables need to utilize these data structures to perform reliably. In terms of efficiency, Linked Lists are most optimal for recording and storing data, while Hash Tables are most performant for searching and retrieving of data.