week 7 summary

Gergő Pintér, PhD

gergo.pinter@uni-corvinus.hu

wireframing

  • responsibility of the UI/UX designers
  • occurs during the exploratory design phase
    • experimenting
  • iterative process
  • iterations are presented to the stakeholders to gain feedback
  • some professional tools: Figma, Balsamiq, Sketch
    • any drawing/diagramming tool can be used for the low or mid fidelity wireframes
Interaction Design Foundation [1] | CC BY-SA 4.0

based on: [2]

wireframe

  • a wireframe is an outline / blueprint / concept art of a webpage or application
  • can be hand drawn on paper or built out digitally
  • provides visual understanding of page structure, layout, user flow, functionality and intended behaviours
  • presented to stakeholders before the interface is coded

source: [2]

types of wireframes

low-fidelity
mid-fidelity
high-fidelity

wireframe map

shows user flow, ~ user story map flow

software design and architecture stack

based on Khalil Stemmel’s figure [3]

hierarchy in style guides

not just style guides, also best practices

write idiomatic code

  • a prog. language implements a prog. paradigm
  • a paradigm defines a certain “way” of writing code
    • using different abstractions / building blocks
    • promoting a given concept
  • some languages implements multiple paradigms
  • and languages have their own way of doing things
    • languages have pros and cons for a given problem

just as in the case of natural languages, you ought to use a language properly

clean code / meaningful names [4]

  • use intention-revealing names
  • pick one word per concept
  • avoid disinformation
  • make meaningful distinctions
    • don’t use names like doSomething() and doSomething2()
  • use pronounceable names
  • use searchable names
    • “The longer the scope of a function, the shorter its name should be.” – Robert C. Martin
  • avoid encodings
    • intNumberOfDays = 0
  • don’t pun or use humor, be professional

names for classes, functions

  • a class is a model / blueprint of something
  • the name should be a noun
    • e.g., User, Activity
  • an object is an instance of a class
    • still a noun
    • e.g., user = User()
  • a function does something
  • the name should contain a verb
    • in imperative
    • e.g., aggregate_activity
    • activity_aggregation

clean code / functions [4]

  • “Functions should hardly ever be 20 lines long” [4]
    • shorter functions are easier to understand
  • do one thing (single responsibility principle)
  • “The longer the scope of a function, the shorter its name should be.” – Robert C. Martin
  • do not use more than three arguments
  • do not use flags
  • no side effects
  • prefer exceptions to returning error codes

clean code / comments [4]

avoid

  • journal comments
  • noise comments
  • writing something that is already in the code
  • closing brace comments
  • separating comments

however, comments can be used if they help to understand the code

  • legal comments (licence information)
  • informative comments, that explain what is happening
  • documentation
by Oliver Widder (Geek and Poke) CC BY 3.0

references

[1]
Interaction Design Foundation, “What are prototypes?” https://www.interaction-design.org/literature/topics/prototypes , 17-Oct-2019.
[2]
L. Bruton, “What is wireframing? A complete guide.” https://www.uxdesigninstitute.com/blog/what-is-wireframing/ , 08-Sep-2022.
[3]
K. Stemmler, “How to learn software design and architecture.” https://khalilstemmler.com/articles/software-design-architecture/full-stack-software-design , 28-Sep-2019.
[4]
R. C. Martin, Clean code: A handbook of agile software craftsmanship. Pearson Education, 2009.