| COMPANY: | CA for NCI |
| TEAM: | Myself |
| MY ROLE: | UX Designer, Visual Designer, Developer |
| TOOLS: | OmniGraffle, Sketch, FileMaker, Xojo |
| CODE: | FileMaker, Xojo |
| TIME: | Jan – May 2014 |
UX Research + UX Design + UI Design + Development
THE BRIEF
There is a lot of creative people who struggle trying to price artwork and track profits and losses. Some applications on the market try to address these issues, but usually, they don’t meet all the requirements. This project focuses on the pricing feature of the system and tries to improve the speed and accuracy of the manual pricing method.
KEY CHALLENGES
The main challenge is to create advanced price calculation system with as few as possible input fields. It should make process of pricing handiworks more efficient. It should remain flexible, so artisans from different craft sectors can use it. For example names of fields should be more general, the user should be able to edit lists of categories.
RESEARCH
…
ESTABLISHING KEY AUDIENCES
The main audience of this application are individuals creating unique art and craft goods out of various materials, so the application should help them track stock, supplies, keep vendors’ contact details, manage wasted materials, keep track of labour time, generate price lists and reports. It should have general tools like back up, export/import, reset; and settings like targeted annual income, currency, days of work per week, admin hours, holidays, tax, etc.
PRICING FORMULA
The IPSA’s pricing system is based on the following formula:
(Materials + Labor + Indirect Costs) * Price Markup = Piece Price
The application should be able to calculate:
- The exact hourly rate an artist should be charging.
- Overhead costs.
- Total used material costs for pieces.
- Wholesale, Direct and Retail price.
To calculate all the above user has to specify:
- How much gross annual income he would like to make (before taxes and expenses).
- How many weeks a year he is going to work.
- How many hours TOTAL he will work a week.
- How many hours (from working week hours) will be spent on admin tasks?
UNIT PRICE CALCULATION
The diagram below shows how the material Unit Price will be calculated. The Unit Price is derived from the lot price and includes costs of purchase (shipping, discount, etc)
CALCULATING MATERIALS IN STOCK
..
CALCULATING PIECES PRICE
First we need to calculate cost of raw materials to create a piece:
ANALYSIS
…
CREATING SCENARIOS
I use scenarios to describe the stories and context behind why a specific user or user group comes to the site. They note the goals and questions to be achieved and sometimes define the possibilities of how the user(s) can achieve them on the site.
USE CASE
…
FUNCTIONAL REQUIREMENTS
The system should have the following functions:
View / Add / Edit / Delete Records
This function allows the user to view/add/ edit/delete records in the appropriate categories of the database. The system has six main inventory tables: “Suppliers”, “Purchases”, “Materials”, “Labor”, “Expenses” and “Pieces”.
Add a new type of material/piece
This function allows the user to create a new type of material/piece category.
Import of materials / pieces / suppliers / orders
This function allows the user to transfer data into the database from other systems. Import is possible for all main tables inventory tables. User maps the fields manually. If there is no corresponding field, the system will create a log file, which the user will check manually.
Search
This function enables the user to perform the search. The user types a query in a textbox and clicks on the “Search” button. The user can also constrain the search by one or more attributes that are available to choose from. In addition, the user can also make combinations of the chosen attributes by choosing AND, OR, or NOT. In both cases, the entry is searched as a case-insensitive substring.
Create / print reports
There will be a standard list of reports in the system. This function allows the user to create / print report. There are reports: – Supplies List / Catalog; – Supplies Usage; – Orders List; – Suppliers List; – Labour per Piece; – Labour per Month; – Expenses List; – Pieces List / Catalog; – Price List of selected items; – Piece Details Sheet;
Help
This function guides the user on how to use a particular feature.
Global Settings
The user can set global variables which will be used for price calculation: – annual income – days of work per week – holidays
Categories
Materials and pieces can be categorised. The user can: – add new category or group – edit list of categories – remove existing category
Add New Purchase Order
The user of the system can add a new purchase order. The data inserted with every purchase order are: – number of the order – vendor – date of the purchase order – total – post cost The inserted data is validated. It means that date, total, post cost have to be inserted in a proper format.
Edit Purchase Order
The user can edit existing purchases: – change total, – change date, – change post cost, – add items from the materials list
Add New Material:
The user of the system can add new material. The inserted data is validated. It means that date, total, post cost have to be inserted in a proper format.
Generating Piece Details Sheet:
The user can generate a piece details sheet summarising materials used, costs involved, labour time …
Generating Pieces Price List:
The user can generate a pieces price list with selected pieces.
APPLICATION SCHEMA
SETTINGS
The user can access here some general settings of the application. The most important are global settings connected with pricing. Based on them all product prices will be calculated
SUPPLIERS
This is a contact management module developed in this system which stores all the vendor contact detail information and has the following functionalities – Supplier Addition/Search, Show All and Record Navigation.
PURCHASES
This section allows adding new purchase orders. It keeps track of the Purchase Orders of materials from different Vendors. Each purchase order has many materials. Additional costs like the post, tax, discount are included in the final Unit Price of the materials. They are distributed proportionally between all materials of a given purchase.
MATERIALS
This module allows new entries in the inventory for different types of materials. It keeps track of relevant material data. It has the search functionality which allows the search for a particular material on the user entered criteria. It has the printing functionality built which allows the users to print the inventory detail or report. The materials are supplied by vendors which are maintained in the Suppliers module. All the vendor information and their contact details are maintained in the system.
LABOR
This module manages timing sessions. Each piece can have many timing sessions. For every timing session, we can set the start and end date. The system will calculate total labour time and cost, for each piece.
EXPENSES
This module keeps track of indirect costs. The system will include expenses in the pieces price.
PIECES
The Pieces section stores all the goods created by the artisan along with their detail information. There are options to add/edit/delete items from the system. The system has the functionality to add multiple materials for a piece and vice versa.
DESIGN
…
FILEMAKER PROTOTYPE
The prototype of the database was developed with the FileMaker Pro.
With FileMaker it possible to test all of the elements involved – data storage, calculation engine, interfaces, media requirements – quickly and easily.
It is easy to set up and configure The graphical nature of the layouts and pick lists and all the other GUI items make this a perfect tool to just get a database application done quickly.
It had helped to:
- Create mockups of the user interface, to check how a user would interact with the application.
- Develop the structure of data storage requirements.
- Test the calculation engine running within the app.
- Get an understanding of how everything will interact: how user input is captured, processed and stored, what will be outputted and how errors will be handled.
DEVELOPMENT
The application will be developed with Xojo IDE and will use SQLite database. The Xojo is a cross-platform, rapid development technology which recently is gaining popularity.
Implementation of the system would bring important benefits like:
1. Time-saving.
2. Less paperwork.
3. Connecting to the database so we use a different type of queries, data report.
4. Give facility of different type of inquiry.
5. Formatted data.
6. Data are easily approachable for multiple users.
7. Friendly user interface.
TECHNOLOGIES
The initial prototype of the IPSA was built with the FileMaker Pro 13. FileMaker is the leader in easy to use database software and it is a great tool for rapidly-built fully functional prototypes. It is often called the OS X version of Access.
As the main goal of this project is to create a native Mac OS X application, Apple’s software development kit was used initially. The SDK is built into Xcode, Apple’s own development environment. Objective-C, Cocoa, Xcode is a very complex technology and there was a risk of not delivering the project on time. The decision was made to switch to faster and more intuitive technology – Xojo.
Xojo (http://www.xojo.com/) is more approachable than Apple’s SDK and more powerful than FileMaker, it is “just right”. It is a rapid development environment and object-oriented language. It supports SQL databases and database migration from FileMaker isn’t very difficult, so it was a perfect choice for the implementation of this project.
Migrating a FileMaker application to Xojo was a three-step process: – the database itself was migrated, – the forms that are used to manipulate the data – the scripting code. The IPSA utilises the built-in Xojo SQL Database as its data source. Xojo abstracts all but one of the database classes that the developer uses from the data source. This means that we can write an application using Xojo SQL Database engine and can change just a few lines of code that create the Database subclass instance to move the entire project to another data source. For desktop applications, the DataControl control is a simple way to map fields to database tables and columns without having to write a lot of code.
The IPSA is written specifically for the single-user Xojo SQL Database. It can easily be modified to support multi-user applications that use the optional Xojo SQL Server database.
Once the Xojo project was finished a standalone application was built for the Mac OS X platform. Cocoa, current user interface framework supported by Apple on OS X is the default Architecture build setting for OS X apps.
DATABASE DESIGN
The system will utilise SQLite database with the following structure:
USER INTERFACE
The user interface for the IPSA database is straightforward. It uses one window which has a large tab panel that contains seven tabs: for Settings, Suppliers, Purchases, Materials, Labor, Expenses and Pieces.
Each tab except Settings contains what are referred to as a “List View” and a “Detail View” for the data related to each tab. The ListBox control at the top of each tab is the List View, and the GroupBox at the bottom of the window and all of the controls contained within it make up the Detail View. When a row is selected in the List View all of its information is shown within the Detail View.
Above the List View is a row of controls that is used to search the table. This makes finding and navigating to a specific record or records much easier than browsing through the list. The information for the record selected in the List View is automatically displayed in the Detail View.
Clicking the New button just above the Detail View enables the controls within the Detail View groupbox. After entering the data for the new product, order, or customer, clicking the Save button will create a new database record and save it to the database.
When a record is selected in the List View, the controls in the Detail View are enabled, allowing changes to be made. When the user is finished making changes, he should then click the Save button to save the changes to the database back-end.
The Delete button removes the record selected in the List View from the database. This dual-purpose nature of the Save button (assuming the roles of separate Add and Update buttons) is done with very simple programming and is an example of how to hide the inner workings of the program from the end-user for a better experience.
The other buttons above the Detail View, such as Show Purchases or New Purchase on the Supplier tab, trigger macros that perform a small number of actions, saving users a little bit of time and hassle. For example, clicking Show Purchases when a customer is selected in the Suppliers tab List View switches to the Purchases tab and enters the necessary information in the search area so that the results in the List View are only those orders that belong to the selected customer.
Xojo Desktop Application Structure
1. The Application Class
The Application class is used to create a subclass that represents the application. When we create a new desktop project, a subclass based on the Application class is added to our project automatically. This is the App class in the Navigator. The Inspector indicates that its Super is Application. On this App subclass is where we specify the default window that opens when the application starts, the default menu bar that is used by the application and the application icons.
2. Event Handlers
The Application class for a desktop application has these event handlers:
Open: This event handler is called when the application first starts, either by running the application directly (in debug mode) or by running a built application
When IPSA is loading the first thing it needs to do is connect to the database. We have a property on the App class that will hold our database connection and can be accessed from anywhere in the application. We will only connect to the database once and then we will continue to use that same connection throughout the entire project.
3. Properties
A property is a value of a class, such as a control of a Window. Changing property values allows us to change the behaviour of the class.
DefaultWindow: This is the window that is opened automatically when the application starts. MenuBar: This is the primary menu bar for the application. It is used as the default menu bar for newly created windows. This property is accessible by the App function.
Icon: This opens the Icon Editor and lets us specify the various size icons that are used by the application.
4. Scope of the App Class Properties, Methods and Constants
We can set the scope of properties, methods and constants of the App subclass using the same rules as for any class. The global App function gives us a reference to the App class in our project so that we can access its public properties, methods and constants. If we have subclassed App, the then App function gives us a reference to our subclass instead. To access a public property somewhere in our project, we would write it like this:
value = App.MyProperty
FUTURE PROSPECTS
Web Application
The system will be implemented as a desktop database application for Mac SO X. Another possibility is to build it as a web application. It could support multiple users and it would be good for artisans who work together and share the same inventory.
Mobile App
The IPSA could also evolve into the mobile application. This solution gives great marketing possibilities. It’s not difficult to imagine, that artisans can’t carry their goods all the time. Having access to the latest product catalogues on a mobile device improves marketing. In the end, it’s all about the customer. Artists could present their work whenever they meet a potential buyer.
Synchronised with Server Server
synchronisation for desktop app is another good direction to go. One central database would make possible accessing data from many different devices.
Security
With all of the above, security would be an issue. Some sensitive company data could be exposed to a threat. Developing security mechanisms would be a necessity.
Etsy plugin
Etsy is one of the biggest online marketplaces for the art and craft people. It also supports developers and various useful plugins are available. Developing an Etsy plugin for listing products directly from the IPSA is a great idea. The next step could be support for other online shops like eBay or CMSs like Prestashop, so the users could avoid headaches with listing the same goods in several e-shops and tracking the sales.
POS
It could also become a fully functional POS. That requires adding several new tables to the system like Customers, Invoices, Sales, etc. There is a lot of good POS systems available on the market and, probably finding a way of connecting IPSA with them would more reasonable solution than developing whole new POS.
Events
Artists put a lot of effort into organising venues, exhibitions, preparing for market fairs. It requires making plans and preparing a budget. Adding a calendar and event management feature could address that need. The IPSA could help to calculate all costs related to the event organisation.
Prefixes
With the huge number of supplies and goods, labelling everything properly is crucial. The IPSA could support generating prefixes and label printing, so all the materials are easy to find.
Scanner
The support for a receipt scanner is another way of improving IPSA. It could be a great aid for artisans who buy a lot of materials and entering it manually into the system takes them a lot of time.
An interactive game to motivate you for sports and bring out your inner hero.
User experience design is an ongoing process.Products and user experiences can constantly evolve.