Skip to content

old MVP

ipsod edited this page Feb 25, 2016 · 1 revision

Introduction

This is still a work in progress. It needs more added, and probably needs some culled, too.

I’m not really sure how much of this should be in the “minimum” viable product - I want all of this functionality, but am not sure where to draw the line for what is “minimum”. Maybe I need to cut it way back?

I have PHP code that handles a lot of this functionality already, so a lot of it will be able to be ported instead of written from scratch. Also, many parts of this functionality have already been through one or more iterations, since I’ve built the same functionality in other languages and frameworks.

One problem I’m having in particular is that, while everything is kind of separated into its own group of concerns, there are little leaks between different sections that I don’t see any way to cure. Bills are a type of Transaction, and Transactions are a part of a Creation, and ShopItems are Things, and Photographs are Images of Objects, etc.

Special Functionality

  • This stuff may be too abstract to approach yet.
  • Might be best to just utilize HTML (org-mode export? Zim wiki integration?) and some form of static-ish pages.
    • I want to have ad-hoc database access, which may be ugly.
      • Will generate cached pages to avoid slow load times.

Folder

  • Folders are in a hierarchy (mptt?)
  • Every row in every database is associated with a Folder.
  • The database table has a folder above its rows in the Folder hierarchy.
  • Like a directory, a folder has a name and directory contents.
  • Each Folder has an Inscription, which gives it a powerful way to communicate its contents (and more).
  • Custom filters may be defined for Folders.
    • Custom Folders may be made with static filters.
      • For example:
        • one folder may contain all products (no filters)
        • another may contain all marbles
        • another folder might contain all products under $20.
  • Folders do not have to be associated with any database row or table at all.
    • If a folder exists, and then a database row is later created that uses its namespace
      • the user will be asked what to do, with the default action being a merge, and the first option being to rename the folder

FolderCover

  • Every Folder has an FolderCover.
  • Uses a special wiki-type text field that allows other tables and rows to be referred to.
    • For example, it might include [Thing 363][main_image], or [Thing 363][url].
  • Basic implementation is HTML with some variables for retrieving data.

Internal Backlinks

Internal Backlinks are pulled from Inscriptions and stored in a database. Thus, we can easily find all links to Product 363. These should be filterable - for example, we might want to find all Tools that mention Product 363.

FolderTemplate

For now, might not need to be anything beyond Django’s views.

  • Custom Templates may be provided for any Folder’s subfolders.
  • Templates provide a custom way to lay out content.
  • Templates may be applied to individual folders.

Guage

For now, might not need to be anything beyond Django’s views.

  • Guages are ways to display a single unit of data.
    • This is more a guideline than a rule.
  • A Guage may access any data available to the folder it is embedded in.
  • Guages use the same markup as Inscriptions.
  • Guages may be embedded in FolderTemplates and Inscriptions.

Dashboards

For now, might not need to be anything beyond Django’s views.

  • The purpose of Dashboards is to combine Guages into a meaningful set.
  • Dashboards are only conceptually different than Guages - there is no difference in implementation.
  • Dashboards may contain other Dashboards.
  • Guages may contain Dashboards, but that would be bad practice.
    • I only mention that it’s possible to reiterate that Guages and Dashboards are the same.

Special fields

Measurement

https://github.com/coddingtonbear/django-measurement

Money

https://github.com/django-money/django-money

Database Tables

Projects

Project __TABLE__

  • A project is a defined outcome to be achieved.
    • It is an objective.
  • Projects are hierarchical - some projects have sub-projects.
  • Projects and tasks are very similar.
    • both can have:
      • status
        • maybe, deferred, ready, started, waiting, delegated, done, canceled
      • due datetime
      • scheduled datetime
      • priority
        • A=high, B=medium, C=low (should be easy to customize)
      • Person as AssignedTo
  • Sometimes Tasks will grow into Projects, and sometimes Projects will shrink into Tasks.
    • It should be easy to convert a Project into a Task and vice-versa.

      Tasks and Projects are different enough that this could get complex, and should be done later.

      • Tasks cannot have sub-projects or sub-tasks, so there should be a check when converting

Fields

status
due datetime
completed datetime

Relationships

has one Project as Parent
has many Task
has one Person as AssignedTo

Task __TABLE__

  • Tasks are concrete steps to achieve the objective of the Project.
  • A task must be doable, like in the Getting Things Done system.
  • Tasks should be sortable.

Fields

status
datetime completed
datetime due
date scheduled
time scheduled

date scheduled must be set for time scheduled to be set

time estimates
  • A list of time estimates - first is first, last is most recent.
  • Always refers to the total amount of time to complete the task - not just time remaining.
time estimate

The most recent time estimate.

time remaining
  • calculated using most recent time estimate minus time spent
  • if it is updated, a new time estimate is made by adding it to time spent
time spent

calculated from TaskWork - not stored in this table

Relationships

belongs to Project
has many TaskWork
has many PrerequisiteTasks
has many PrerequisiteProjects

TaskWork __TABLE__

Fields

name
description
begin time
end time

Relationships

belongs to Task

Recipe

Whereas a Project is a concrete set of specific actions, a Recipe is more of a template for a Project.

  • It should be fairly easy to use a Recipe as a template for a Project.
  • It should be fairly easy to derive a Recipe from a Project.

RecipeStep

Whereas a Project has Tasks, a Recipe has Steps. Steps should be sortable.

Fields

Relationships

has one Recipe

Things (physical objects)

Thing __TABLE__

  • Things are actual objects in the physical world.

Fields

Measurements
  • Each physical thing is going to have a different set of measurements.
    • Some, like spheres, might have only diameters.
    • Others, like spinning tops, might have:
      • a “spin time” to measure how long they can spin
      • a height
      • a diameter
  • A Thing might have a monetary value.
    • Like other measurements, the accuracy of the measurement depends on the skill of the measurer.
    • Unlike other measurements, monetary value is not a very concrete concept.
      • What some people sell as art for millions is really more of a tax fraud.
      • What other people sell as art for millions may actually be worth it.
      • It’s hard to know the difference.

Relationships

has many Things as Parts
  • A thing might be made of many other things.
  • Parts should be easily removable
    • paint is not a part, but a material.
    • a bolt is a part
  • Parts should only be defined if it seems useful to do so.
has one Thing as Conglomerate
  • If this Thing is a bolt in a larger machine
    • then this Thing is a Part and the machine is the Conglomerate.

ThingCategory __TABLE__

Fields

Relationships

has many Manufacturer

Creation

Creation is an inter-mixing of actions and the things they produce

Instructions(Recipe)

Creation(Project) __TABLE__

Fields

Relationships

has many Thing as Product

CreationStep(Task) __TABLE__

Fields

Relationships

has one Transaction

The giving of a thing, some time, and the creative forces at my disposal (thought, training, intuition, etc.) to gain another thing may be thought of as a transaction.

  • On the opposite end of this transaction from myself is … ?
  • This sort of transaction is where righteous wealth should be built.
has many Person as Contributors

Maybe the person should not be related here, but just referenced through the Transaction?

has many Person as Artist

Even if a hundred people helped make a Tool album, Tool is the Artist. But, then, there are collaborations between bands, so there should be many Artists.

has many Component
  • Components are destroyed in the process of creation.
  • Components may be either entirely destroyed or partially.
    • For example, using some tape does not destroy the whole role, but it does take some of it.
has many Material
has many Technique
has many Thing as

CreationStepWork(TaskWork) __TABLE__

Material(Thing) __TABLE__

  • This is a material of manufacture.
  • Unlike Components, Materials cannot be easily removed from the Product.
  • This does not refer to a category of Materials, but a specific instance.
    • For example, not “a banana,” but “this banana”.

Fields

Relationships

Manufacturer
belongs to Transaction as Acquisition

Transaction it was acquired in

MaterialCategory __TABLE__

Should this even exist, or should it be subcategory “Thing/Material/…”

Fields

Relationships

Component(Thing) __TABLE__

Unlike Materials, Components are easily removed from the things they become

Fields

Relationships

IsProduct
  • Often, components are not bought but made.
  • Since a Thing may be both a Product and a Component, what is the proper way to represent this in the database?
UsedInProduct
  • A Thing is not a Component unless and until it is used in a Product.

ComponentCategory __TABLE__

Should this even exist, or should it be subcategory “Thing/Component/…”

Fields

Relationships

has many Component

Technique __TABLE__

Fields

Relationships

has many CreationStep

Manufacturer __TABLE__

Fields

Relationships

has many ThingType as TypesOfThingsMade
belongs to Person as IsPerson

Distributor __TABLE__

Fields

Relationships

Transaction __TABLE__

  • Transactions are very generalized in this system.
  • The process of making a sale is a transaction of goods for money.
    • The two parties of this transaction are easy to define.
  • The process of making a marble is a transaction of materials, components, time, skill, etc. for a marble.
    • The first party of this transaction, the artist, is easy to define, but the second party is mysterious.

Fields

status
date_completed

Relationships

has many TransactionEntry

TransactionEntry __TABLE__

Fields

date
gives
receives

Relationships

belongs to Person
belongs to Transaction
has many Parcel

Images

I’m not sure that I’ll have to do anything special with images - they may be handled perfectly by sorl-thumbnail.

Photographs

  • Photographs are a specific type of images that are a capture of the real-world.
  • Photographs can have additional data that images typically don’t, like:
    • location the photograph was taken
    • datetime the photograph was taken
    • people, places, or things captured in the photograph
    • information used to scale an object in the photograph to proportion.
      • a line on that photo that defines two points in the photograph
      • and a measurement that gives the distance between those two points
    • information about the lighting set-up, photography equipment (and its settings), etc. used in capturing the photo

Photograph __TABLE__

Fields

lighting
image
title
description

Relationships

belongs to Location
belongs to Camera
belongs to Lens
belongs to PhotoShoot
has many Light
has many Thing

Things can be in photographs

has many Person

Persons can be in photographs (but really, maybe just humans and places?)

ThingPhotographScale __TABLE__

  • Used to create photographs that are scaled to proportion
    • used to make, for example:
      • a gallery of things accurately proportioned to each other
      • an image of the thing next to a quarter for scale

Fields

x1
y1
x2
y2
distance (Measurement field)

Relationships

Thing
Photograph

PhotoShoot __TABLE__

Since many photographs are part of the same PhotoShoot, they have the same lighting set-up, camera set-up, etc., and instead of defining that stuff for each photo individually, it can just be defined for the shoot.

I’d like to have the ability to start a new PhotoShoot as a copy of an old one, since I usually don’t change much between each shoot. This should actually be default or at least very quick to do.

Camera __TABLE__

CameraConfig __TABLE__

CameraLens __TABLE__

LightBulb __TABLE__

Used to define a specific type of light bulb - useful for remembering stuff about photography and videography.

Contacts

Person __TABLE__

Using legal definition of person - can be corporation

Fields

Relationships

Corporation __TABLE__

A special type of person that has no soul.

Human __TABLE__

A special type of Person that actually is a person

Shop

I want to develop everything else before this, but I want everything else to be developed with the consideration that this will someday exist.

I don’t expect this to be terribly hard to develop, as I’ve already got a working prototype in PHP.

  • Most online stores are set up more to deal with categories of things than specific things. That is to say, they are not selling the exact physical object in the photograph, but one just like it.
  • My shop will usually be selling the specific thing in the photograph.
    • Should there be different methods:
      • for selling specific things, like this exact marble
      • and for selling generic things, like one of these stickers
  • The shop is based around Bills.
    • The cart is a Bill, WishLists are Bills, and Bills are Bills
  • Calculating sales tax, shipping, etc. can be hairy.
    • I will used fixed price shipping - one price for U.S., one price for international.
    • I will charge 8.25% sales tax for sales within Texas.
    • I will give free shipping for orders over $XX.
    • The ShippingCalculators and StateSalesTaxCalculators should be extensible and/or replaceable.
      • Every ShippingCalculator that is valid for the Cart will be shown as an option for shipping.
    • Shipping is taxable in some states, and not in others, so there should be a replaceable BillCalculator that implements the other calculators.
    • The cart page should have a place to enter zip code to calculate tax and shipping
      • there should be only this one step between a Client and their Total

They have monetary values, also, which may also be a measurement.

  • “Manufacturer Suggested Retail Price” might be one such value
  • “Best price found” might be another.

If an item sells while it is in the cart, so that the quantity in the cart are no longer available, then the cart quantity should be updated and the user should be notified when they next visit the cart page.

If the Client tries to add to Cart more of an item than are available, then no items should be added to the cart, and the user should be notified immediately by ajax.

Client __TABLE__

  • Not a web client - just the same thing a business would mean if they said “a client.”
  • Might be accessing the web, or might be calling in an order.
  • A client is anyone that receives a bill.

Relationships

has one Person as IsPerson
has many Bill as Bills
has many Bill as WishLists
has one Bill as Cart

Bill(Transaction) __TABLE__

Fields

status

cart, wishlist, bill, paid, shipped, paid and shipped, abandoned

items_total
shipping_total
tax_total
total
receipt

text file? image

Relationships

has one Client
has one Address as DeliverTo
has one Address as BillTo
has many Item
has one ShippingService
has one Transaction

BillItem __TABLE__

Fields

quantity

Relationships

has one ShopItem
has one Bill as Cart

Address __TABLE__

Fields

status (could be expired)

Relationships

has one Client

ShopThing __TABLE__

  • This is an item in the store.
    • just a price and a relationship to a Thing
  • Will eventually need to be able to add shipping information on these
    • some items cost more than others to ship
    • for now, since everything I’m selling is small, I’ll just use flat-rate shipping, so no shipping info needed

Fields

retail price (money)
sale price
quantity available

Relationships

has one Thing
  • Could be a Product or just a Thing.
    • anything that implements the Thing interface?

ShopThingCategory __TABLE__

  • This is not a category to place ShopThings under, but a more generic ShopThing.
  • Used to sell items that are more or less reproducible.
    • Not “the exact sticker in the photograph” but “one just like it”.

ParcelCarrier __TABLE__

ParcelService __TABLE__

Fields

Relationships

belongs to ParcelCarrier

ShippingService __TABLE__

  • Needs to have functions for calculating shipping
    • maybe they’d be in some supporting class
    • maybe models should have more data than calculation?
  • Special requirements, like bill.total > $40?

Fields

Relationships

ParcelService

Payment __TABLE__

  • Not sure how to handle payments.
  • Would like to have payment processors interchangeable and be able to use muliple
    • Could be Square, PayPal, cash, check, Stripe, etc.
Clone this wiki locally