ERD entities and attributes – written + Drawn

IMG_0614IMG_0612 IMG_0613

User (Entity)

User_Id Integer, Auto increment Primary Key

User_FirstName Characters

User_Lastname Characters

User_Email Characters

User_Password Characters (20)

User_Bio characters

User_rating Integer


User_Persona – composite key

User_Id Integer, Auto increment Foreign Key

Persona_Id Integer Auto increment Foreign Key


Persona (entity)

Persona_Id Integer Auto increment Primary Key

Persona_Label characters

Persona_AvergaeAge Number NULL

Persona_Income Integer NULL

Persona_GenderSkew characters NULL

Persona_Goals characters NULL

Persona_Challenges characters NULL

Persona_Objections characters NULL

Persona_Hates  characters NULL

Persona_Notes characters NULL


Industry (Entity)

Industry_Id Integer Auto increment Primary Key

Industry_Label characters



PRIMARY KEY (IndustryId)




Role (Entity)

Role_Id  Integer Auto increment Primary Key

Role_Label characters

Role_IndustryId Integer


Comment (Entity)

Commet_Id Integer Auto increment Primary Key

Comment_Text characters

Comment_Date date

Comment_UserId Integer



User_Persona – composite key

User_Id Integer, Auto increment Foreign Key

Persona_Id Integer Auto increment Foreign Key

ERD entities and attributes – written + Drawn

Getting to grips with SQL

Bill Weinman MySQL essential training run through

After watching the database essential training videos and creating my first entity relationship diagram models I have moved on to the creation of actual databases. I am running through the MySQL essential training as a way to quickly get a good grasp of how the database is built and how I should go about building it.

In theory after creating my ERD model and then going through the MySQL training I should be able to piece together my database in a working prototype of some form. However for the artefact I will be handing in a working database of some kind and the ERD, not the completed database.

The first step here was setting up the correct environment on the pc I am using, this involved setting up a web server called xampp which is a “a free and open source cross-platform web server solution stack package, consisting mainly of the Apache HTTP Server, MySQL database, and interpreters for scripts written in the PHP and Perl programming languages.” This basically allows me to work with databases without requiring my own server.

After setting up the server I went on to make my the localhost user secure with a password and create a “web” user with minimal permissions (SELECT,INSERT,UPDATE,DELETE,FILE). Along with the SID user for the tutorial. The exercise databases where then imported into MyphpAdmin.

After running through the course I have created my first Database with the individual tables, translated from my ERD. However I am still working on creating the FK and dependencies and also have no actual data to fill them yet. But as I continue to research I will gather more to fill them. Below is some of the code I have put together, It’s still simple but I intend to build it up as I improve.




PersonaId MEDIUMINT NOT NULL AUTO_INCREMENT, PersonaLabel TEXT NOT NULL, PersonaAverageAge INT, PersonaIncome INT, PersonaGenderSkew TEXT, PersonaGoals TEXT,

PersonaChallenges TEXT, PersonaObjections TEXT, PersonaHates TEXT, PersonaNotes TEXT,













PRIMARY KEY (IndustryId)







Getting to grips with SQL

Entity Relationship Modelling

A short guide to designing Entity Relationship Models using Barker’s notation.

By Frankie Inguanez

Frankies take on ERD is more in-depth that the previous video tutorial, whilst also being slightly harder to understand unless you really break down each section. As I work through the document I aim to write down and record the various key elements as a way of both demonstrating that I have understood the material to myself whilst simultaneously making notes which I can look to in the future when designing my own ERD databases. This material also specifically uses Barkers notations which is a variation of the crows foot notation seen previously.

It was half way through taking notes that I came to the realisation that it was complete overkill and I was essentially just repeating what he had written down first. So I have chosen to use his sheet as my guidelines rather than recreate his work, I included the notes I did take before stopping in this blog post.

General Rules of ERDs

  1. Capture all required information.
  2. Information appears only once.
  3. Model no information that is derivable from other information already modelled.
  4. Information is in a predictable, logical place.

Key elements

Entity – is again the top element, this again represents a table with an entity instance being a single record or “row” of the table.

Attribute – is again the property of an entity which describes a characteristic of particular entity instance. However while the previous work featured primary keys and identifiers as a separate element here they are listed as a type of attribute. These three types are

“a. Unique Identifier: A UID is an attribute whose value uniquely identifies an entity instance. A UID is implemented as a Primary Key.

  1. Mandatory Attribute: A mandatory attribute is one whose value cannot be null.
  2. Optional Attribute: An optional attribute is one whose value can be null.”

Relationships – Links two or more entities (tables) together. Here a relation is implemented as a foreign key, therefore the FK “attribute” is not listed as an attribute in the target entity.

Diagram Showing the entity and attribute drawing rules.

Diagram showing the relationship drawing rules.

When drawing the relationships there are a number of rules to follow which I have copied into the diagram with lines showing where they are being used. But to reiterate a relationship must be optional or mandatory and each relationship must be labelled with its perspective according to the entity it is attached to.

Relation ships can be one of three different types

One to one – Pretty obvious, one entity instance relates to one entity instance. The FK or foreign keys relating them should always be placed where A. there is never going to be a null value so in the “must have” entity. Or in the entity which has the least amount of nulls/or rows or the most relevant to the table.

One to many – Each entity is related to multiple entity instances. The foreign key should be placed in entity touched with the crow’s foot, since many rows in B will be related to only one row in A.

Many to many (Always need to be resolved using an intermediary or transactional table)



Entity Relationship Modelling

Database design essential training

This tutorial from proved to be far more accessible than the ERD found on folksonomy mainly because it looked at the whole of database design from the beginning while Frankies looked more at how to technically go about designing a database using a specific set of rules. While this is no doubt a useful way of doing it the full knowledge of database design is required I feel before jumping into the technical way of designing them. Just like it more useful to understand how code or programming works before attempting to create something using the code.

Below is my notes from the videos, My ERD will created using these and show in my next blog post.

Key Points

  • It’s ideal to be methodical and take you time.
  • It’s best to start ultra-simple and work your way up.

First what’s the point?

To allow users to create and manage marketing personas and allow them to shared and  contributed to by multiple different users and track the progress and usage of these personas for future development.

What do you already have?

Nothing except theoretical personas information. People, expertise, an existing database? Go over this information and fix any problems you find. I myself had literally nothing as my starting point except the list of information I wanted to be in the database.

What entities (tables) do you have? Generally use singular nouns for these but consistency is key. Picking the most useful or relevant words is the key here.

Users, Personas, Comments, Notes, Updates, Usage, statistics, case studies, Authorship, Industry, Role,.

Next is figure out the attributes of each entity, these will become the columns of each table, while they can be abstract or nonspecific when sketching out first drafts it is helpful to get specific early on. Whilst being granular as possible.

So for my purposes, we have to begin with

The entity’s, work out each ones attributes and then go on to decide the data type with in each attribute should be, as in intergar, character, number ect. Also if they are null or void null

Relationship cardinality

One to one (Rare)

One to many (The vast majority)

Many to many (Requires resolving)

In many ways the database I am building can be compared to a typical learning database ie the customer to order relationship is similar to my user to Persona relationship. A single user can have many personas, but a persona may only be created by a single user (for now)

When and how to use foreign keys

You never change the “one” side you change the “many” side usually by adding the Pk to the many table where it know becomes a foreign key. This acts as the identifier to the table. The FK can be named the same as its primary key original or simply named to showed what it is, like the customer/order example it could be “customerId” or it could be “placed by”

So in my example each Persona (The many table) will have a FK from the user table, identifying who created which persona.

As I develop my ERD while going through the video I am starting to pick out various relation ships which before I thought would be contained within other tables, in particular separating our roles and Industry from personas.

Many to Many

This was where I realised that if I wished to have multiple users able to share and contribute on each persona I would need a linking or bridging table in order to have a many to many relationship for the contributing.

Having just reached the normalisation process in the tutorial I chose this to be a good break point for me to start with the sketching out and early conceptual modelling of the actual data base before I would move onto the more specific and technical areas.

Database design essential training

Entity Relationship diagramming video tutorial

Gina Baldazzi (2013) Folksonomy

“Graphical representation of the data requirements of a database”

After speaking with lecturers I decided that the next element to set about creating for the artefact hand in would be the database from which I will be working. Whether my project changed or altered as I continued the work remains to be seen but databases are generally integral to many pieces of work so it is important that I understand the processes which go into creating one.

I was instructed to look at entity relationship modelling as the first step as this would allow me to learn the fundamentals and also greatly speed up the actual creation of the databases if I had a good structure on which to build. Folksonomy provided and good beginning to this, I found a short instructional video which helped me brush up on what I had learned (having not had a chance to review ERD in a few months). This I will follow with the more in-depth look at it from Frankie Inguanez before designing a prototype data base with some planning help from a lecturer Simon Perkins. After this I will follow some more tutorials curtesy of to help refine and master the ERD before again using to help me create the actual database.

The video while great for someone only really starting to learn ERD did go through a number of the concepts very quickly with little explanation on how they should be created (specifically composite keys) but it did outline the basics very well while also demonstrating how it should be used in a real world scenario.

(EDIT)After reading the YouTube comets on the original post it becomes apparent that there may be one or two mistakes in the tutorial, (but these are youtube video comments) and I still found it useful as a starting point.

Five key elements from the video (Almost word for word)

Entity – represents a person, place or thing you wish to track in a database, This will become a table in the database. Each occurrence of this entity is an entity instance, this will become each record or row in the table.

Attributes – describe various characteristics of an individual entity. These will be the columns in the table, these don’t have to be unique. E.g. first name

Primary Key/identifier – an attribute or group of attributes that uniquely identifies an instance of an entity. This must be unique, as it is used to identify the entity instance. E.g. student number. Sometimes you need more than one attribute to make an instance unique, that’s when you use a composite key

Relationship – describe how one or more entities interact (a verb) with each other. E.g. this entity has a phone number. Essentially a line showing the relationship exists.


Cardinality – the count of instances that are allowed or are necessary between entity relationships. How many rows we need from one table to link it to another table. Showed with crows feet notation. Broken into two parts minimum(fewest rows needed for a relationship)/maximum(cannot exceed a number of rows for the relationship)

The whole Entity Relationship Diagram is designed to act as a blue print for the database.

Entity Relationship diagramming video tutorial

Activity centred design Toolkit

The hear phase of IDEO’s human centred design toolkit was where I first encountered many of the issues which I have been trying to correct since beginning the project.  I was aware that I would need to alter some of the various aspects of it to better suit my needs. However the more I worked through the hear phase the more I was coming a lot a lot of small problems which I couldn’t solve with just small tweaks. The problems where even more exaggerated the further into the toolkit you delved. While it is a great and very useful piece of kit for particular groups it just didn’t suit my needs. The largest whole was the fact that much of the work is highly team based and collaboration focused. While I would be using other people every now and then the majority of “grunt” work within the project would just be performed by me with on experts and specialists used where they needed to be used.

This is what originally led me to start researching other ways of going about the design process but which kept to the ideals of the IDEO toolkit, designing for the user and doing it well. My next step will be to start placing all of the various pieces of information I have gathered into their own design methodology which I can use for my creative project. I intend on creating a design toolkit in the same vein as the IDEO toolkit but specialised to my needs and other web designers and developers. I now intend to produce one which will fix this weakness.

  • Impractical without a team or dedicated space.(Allowances for smaller teams of solo work by factoring in different phase to make up for lack of specialists.)
  • Some elements are very time consuming.(Using activity theory and core affects to speed up hear and early create phase)
  • Not focused on software design.(Working in phases for IA,UI and UX)
  • No real focus on aesthetics or user experience.(Material design)
  • No aesthetic design elements means I need to find a way of doing it myself.(Material Design)

All I need now is a name for the new design toolkit.

Activity centred design Toolkit

Using material design in the redeveloped design documentation


Google material design check list

This material check list from android-developers Google will be my secondary source for information when it comes to the material design aspect of design documentation rather than diving into the mass of documentation when in the middle of fast prototyping having a reference sheet included in the design documentation will be much faster. While Googles own guidelines are in depth and incredibly accurate I have found that when prototyping and quickly coming up with ideas you need something which is slimmer and more light weight to quickly work from in regards to the design.

I am planning on taking the check list and turning into s set of steps which will be integrated into the design documentation as part of the overall creation phase. This will include a method and way of creating material design cards allowing people quick reference to screen sizes and the other hurdles to allow people to throw together a paper and card design in a few minutes without even needing to sketch out the designs in the first place.

The Check list

Tangible Surfaces

UIs consist of surfaces (pieces of “digital paper”) arranged at varying elevations, casting shadows on surfaces behind them.

Signature element: Shadows are used to communicate which surfaces are in front of others, helping focus attention and establish hierarchy.

Shadows and surfaces are used in a consistent and structured way. Each shadow indicates a new surface. Surfaces are created thoughtfully and carefully.

There are generally between 2 and 10 surfaces on the screen at once; avoid too much layering/nesting of surfaces.

Scrollable content either scrolls to the edges of the screen or behind another surface that casts a shadow over the content’s surface. Never clip an element against an invisible edge—elements don’t just scroll off into nowhere. Put another way, you rarely scroll the ink on a surface; you scroll the surface itself.

Surfaces have simple, single-color backgrounds.

A Bold, Print-Like Aesthetic

The “digital ink” you draw on those pieces of digital paper is informed by classic print design, with an emphasis on bold use of colour and type, contextual imagery, and structured whitespace.

Signature element: Apps use a primary colour and an accent colour to colour surface backgrounds and key UI widgets such as text fields and checkboxes. The accent colour contrasts very well with the primary colour (for example an app can use a dark blue primary colour and a neon pink accent colour). The accent colour is high-contrast and is used to call attention to key UI elements, like a circular floating action button, selected tab strips, or form fields.

Signature element: On Android 5.0, the status bar is coloured to match the app’s primary colour, or the current screen’s content. For full-bleed imagery, the status bar can be translucent.

Icons, photos/images, text, and other foreground elements are coloured “ink” on their surfaces. They don’t have shadows and don’t use gradients.

Colours extracted from images can be used to colour adjacent UI elements or surfaces.

Signature element: Icons in the app follow the system icon guidelines, and standard icons use the material design icon set.

Photos are generally immersive and full-bleed. For example, for detail screens, run edge-to-edge and can even appear behind the app bar or status bar.

Signature element: Where appropriate, elements like body text, thumbnails, app bar titles, etc. are aligned to 3 key lines. On phones, those key lines are 16dp and 72dp from the left edge and 16dp from the right edge of the screen. On tablets those values are 24dp and 80dp.

UI elements are aligned to and sized according to an 8dp baseline grid. For example, app bars are 56dp tall on phones and 64dp tall on tablets. Padding and margins can take on values like 8dp, 16dp, 24dp, etc. More precise text positioning uses a 4dp grid.

Authentic Motion

Motion helps communicate what’s happening in the UI, providing visual continuity across app contexts and states. Motion also adds delight using smaller-scale transitions. Motion isn’t employed simply for motion’s sake.

In general, UI and content elements don’t just appear or disappear—they animate into place, either together as a unit, or individually.

Signature element: When touching an item to see its details, there’s a “hero” transition that moves and scales the item between its position in the browsing screen and its position in the detail screen.

Signature element: Ripple effects originating from where you touched the screen are used to show touch feedback on an item.

Signature element: UI elements can appear using a circular “reveal” animation.

Signature element: Animations are used in more subtle, delightful ways, such as to convey the transition between icon states or text states. For example, a “+” icon can morph into an “x” symbol, or an outlined heart icon can be filled using a paint-bucket fill effect.

Animations and transitions are fast—generally under 300ms.

Crossfades are often replaced by translate/slide transitions: vertical slides for descendant navigation and horizontal slides for lateral navigation. For slide transitions, prefer quick acceleration and gentle ease-in deceleration over simple linear moves. See the material design spec on motion for more.

Adaptive Design (and UI Patterns)

Tangible surfaces, bold graphic design, and meaningful motion work together to bring a consistent experience across any screen, be it phones, tablets, laptops, desktops, TVs, wearables, or even cars. Additionally, the key UI patterns below help establish a consistent character for the app across devices.

The app uses responsive design best practices to ensure screens lay themselves out appropriately on any screen size, in any orientation. See the Tablet App Quality Checklist for a list of ways to optimize for tablets, and this blog post for high-level tablet optimization tips.

In material design, detail screens are often presented as popups that appear using “hero” transitions

In multi-pane layouts, the app can use multiple toolbars to place actions contextually next to their related content.

Signature element: Where appropriate, the app promotes the key action on a screen using a circular floating action button (FAB). The FAB is a circular surface, so it casts a shadow. It is coloured with a bright, accent colour. It performs a primary action such as send, compose, create, add, or search. It floats in front of other surfaces, and is normally at an 8dp elevation. It frequently appears at the bottom right of the screen, or centered on an edge where two surfaces meet (a seam or a step).

App bar

Signature element: The app uses a standard Android app bar. The app bar doesn’t have an app icon. Colour and typography are used for branding instead. The app bar casts a shadow (or has a shadow cast on it by a surface below and behind it). The app bar normally has a 4dp elevation.

The app bar might be for example 2 or 3 times taller than the standard height; on scroll, the app bar can smoothly collapse into its normal height.

The app bar might be completely transparent in some cases, with the text and actions overlaying an image behind it. For example, see the Google Play Newsstand app.

App bar titles align to the 2nd Keyline

Where appropriate, upon scrolling down, the app bar can scroll off the screen, leaving more vertical space for content. Upon scrolling back up, the app bar should be shown again.


Signature element: Tabs follow the newer material design interactions and styling. There are no vertical separators between tabs. If the app uses top-level tabs, tabs are visually a part of the app bar; tabs are a part of the app bar’s surface.

Tabs should support a swipe gesture for moving between them.

Selected tabs are indicated by a foreground colour change and/or a small strip below the tab text (or icon) coloured with an accent colour. The tab strip should smoothly slide as you swipe between tabs.

Navigation drawer

Signature element: If the app uses a navigation drawer, it follows the newer material design interactions and styling. The drawer appears in front of the app bar. It also appears semi-transparent behind the status bar.

Signature element: The leftmost icon in the app bar is a navigation drawer indicator; the app icon is not visible in the app bar. Optionally, on earlier versions of the platform, if the app has a drawer, the top-left icon can remain the app icon and narrower drawer indicator, as in Android 4.0.

The drawer is a standard width: No wider than 320dp on phones and 400dp on tablets, but no narrower than the screen width minus the standard toolbar height (360dp – 56dp = 304dp on the Nexus 5)

Item heights in the drawer follow the baseline grid: 48dp tall rows, 8dp above list sections and 8dp above and below dividers.

Text and icons should follow the key lines discussed above.

The checklist is in-depth and useful but will need to slimmed down in order to fit with the overall theme of rapid prototyping, this will be done by pinpointing the key elements for the design document and working them into the overall design phase. It will also be an integral part of what I plan create in the design cards, a readymade and easy to use system which will allow ultrafast prototyping with realistic sizes and forms and ratios so a cleaner and clearer vision of the apps final style can be quickly formed by the users.

Using material design in the redeveloped design documentation

Core Affect and the Psychological Construction of Emotion


Core affect and the pyschological construction of emtion paper by Jmes A. Russell.


“At the heart of emotion, mood, and any other emotionally charged event are states experienced as simply feeling good or bad, energized or enervated. These states—called core affect—influence reflexes, perception, cognition, and behaviour and are influenced by many causes internal and external, but people have no direct access to these causal connections. Core affect can therefore be experienced as free-floating (mood) or can be attributed to some cause (and thereby begin an emotional episode).” James A. Russell

Core affect explanation

Core Affect model (
Core Affect model (

The core affect and the psychological construction of emotions has been used throughout other work in HCI because it allows people to accurately interpret, predict and understand emotions and their context. Core affect see’s the subject has having two axis the pleasure and displeasure and the activation or deactivation. When laid together you can chart where various emotions will be. Core affect is where you are on this model which is being continually reassessed by the subject in an ongoing feedback loop. Emotions are not outside of this model such as “Fear of a bear” this would be on the model of high activation and high displeasure they are all part of emotional episodes which are part of the core affects reassessing and taking in new information.

The emotional episode or feedback loop as I am viewing it works as such

Antecedent event – An external event.

Affective quality – the event is perceived by the subject in its affective quality I.e. how pleasant/unpleasant exciting boring etc. the antecedent is.

Core affect – Core affect begins to change in response to the perceived affective quality of the antecedent event. This is happening continually.

Attribution – The core affect felt is attributed to the antecedent event (Which now become the “object”) that object makes me feel *****

Appraisal – cognitive processing of the object, qualities, future impact on goals/outcomes (This is closely linked to core affect in that the subject is more likely to process qualities which align with their current core affect, I.e. You see the bad in the object when you are feeling bad to begin with.)

Instrumental action – activity is directed at the object in response to its effect on core affect and appraisal. This takes into account circumstances, resources any goals etc.

Physiological and expressive changes – “Facial, vocal, and autonomic changes occur and are accounted for (a) by core affect and (b) as part of, preparation for, or recovery from instrumental action.”

Subject conscious changes – “there is a flood of metacognitive judgments” much feels beyond conscious control and these are aligned with the core affect.

Emotional meta-experience – The subject experiences the emotion of being “afraid” or “angry” a self-perception and categorisation of the current emotional state.

Emotional regulation – deliberate self-control over the emotion with the social and circumstantial rules by the subject.




How it can be used in the HCD project

The model can be easily worked into and integrate with activity theories models to help add more meaning to the links between say outcome/ object and explain why a subject will be attempting to reach that outcome through emotion.

“Decisions thus involve predictions of future core affect (March, 1978). Core affect is involved in motivation, reward, and reinforcement” Which aligns on activity theories cases of subjects performing activities to reach objects which won’t directly benefit the subject, but will in the long run or “predicted future” will results in a positive gain.

I can also possibly use the model to chart where the core affect should start and where it should end after using the software. This gives you a clear guide when designing as to what kind of stimuli need to be included and lets other designers know the journey a user “Should” be taken on when using the artefact.

This model will be excellent and helpful when trying to create or tell an emotional journey for the artefact. It should allow users of the theory to pin point exact areas which are designed to elicit emotions or act as antecedent events and how they should look and feel in order to properly alter the core affect or “emotions”.

Core Affect and the Psychological Construction of Emotion

Artefact redesign redesign

“making my own way”


As I have developed my understanding of both human centered design and other theories and concepts which I am hoping to incorporate into my artefact I have hit upon the notion that the HCD tool kit which I have begun using to redesign the Ascesis blog is unfortunately no longer fit for task and is also does not fit my personal use in many cases requiring large teams and large amounts of unattainable data. While the core concepts are still completely valid it misses out on many areas which are vital to the outcome of the creative project.

This has given me the idea to shift my focus for the artefact away from the redesign of the blog and towards the possibility of redesigning the actual methodology and creating a toolkit of my own which takes into account many of HCI, IA, UX, UI, activity theory, cybernetics and cyborg, theories models and concepts I have been grappling with to create a web design focused document which can brought to bear on any future projects, in particular the creative project.

I will use the IDEO toolkit as a starting point for the creation of the toolkit. Following its format and layout where it makes sense but working in the other concepts I wish to be a part of the methodology. By doing it this way it allows me to tailor the toolkit specifically to my needs for the project and also should results in a better quality outcome when it is used. I will then compile the information into a step by step process and produce a design documents which will be used for the creation of the creative project in the second part of the unit.

Artefact redesign redesign