Django-based TimeBank web app

Since being a dev, this had be to done.

In this article, you will learn ways to think of an in Django (Python-based framework).

UX design story

It is useful to start with a desired goal, the description: A family wants to improve the participation level of children in homework (goal 1). The way to do this is via a simple app. All users within the family should have easy access to the app. Parents can serve chores on the app. These chores are taken by children. When the chore is completed, the chore ticket is converted into game time: adding gaming time for the day, or into future days. When children use Playstations or other gaming devices in the house, the earned play time is consumed.

The mechanism is via “tickets”. A ticket is simply represented as a code, or done fully in-app. Whether the ticket needs textual representation at all, is a good question!

Distill to bare essentials:

• 1 view for time bank — per each child
• 1 view for parent’s chore offers
• a redeeming mechanism of a chore completed, into gaming time

Lets split the original headline a bit:

• Django-based = using a Python-based neat MVC framework
• Time bank = issue tickets based on home work, allow children to redeem them, to get play-time
• home work -based = has utility and teaches that things aren’t free in this world, albeit they seem to be

The backstory is quite simple. I wanted to test doing a useful fullstack app in Python. Since we are talking family life, it wouldn’t hurt to actually do the good old dog-feeding, and use the system in real life. Dog feeding to imply that I use the system, so that it gets indeed very instant feedback from at least one user I know quite thoroughly.

Programming is best when you can immediately use the product in your own life. For me, it’s always been that way. For historical ramblings, see this: Early projects I programmed on a PC | by Jukka Paulin | Dec, 2024 | Medium

There might be others out there,

there might be projects already done to excel in this.

Yet.

There is always.. room for one more Django-based backend exercise!

Django use

I am pretty much following ChatGPT for making a skeleton, a scaffold for the app. Django is a Python-based web framework, that brings certain benefits: it’s so called batteries-included system, having both the backend, and frontend.

Model to web page

Django’s Views generator pushes out HTML to your browser- so it creates the web pages for your views.

Views are nothing but HTML, where the contents is based on what your data is at the moment of production. You can decorate them with CSS to gain full control of the frontend looks, and customize the views to be beautiful and elegant.

Models, the data, simply live as Python program. So in the true spirit of Object-oriented development, Django creates the Models as classes. You instantiate these as living objects, and then Views (the frontend) shows content based on the model values. You can simulate pretty much anything to your souls’ extent, and Django offers a great method for this. You don’t need to actually know that much object-oriented programming. Django management tools help you create the core code for your models. Of course you can edit the generated source code for finetuning logic, as long as you take charge of the edits.

Views are meant to be written so that the Logic (M layer) changes are not included in any view-level code. Views only route back to the Model changing via Controllers ©.

So let’s recap effectively:

• Models (M) hold data — they are the level that makes a “headless” backend. In true actuality, Models are the architectural models of your apps data. Models are then instantiated as Python objects, and then they become useful. Django allows for some up-front software architecture, which pays off usually when you progress to maintenance and upkeep phase in your app.
• With just the Models alone, you could theoretically run and use your app. It just would not look pretty, in fact it wouldn’t “show up” as anything to the user’s browser, but would internally still work, doing the bookkeeping of your web app.
• Controller code relays the user’s actions on web pages towards the backend logic. Controllers are attached to any visible widgets on the web page of your app: buttons, menu items, clickable icons, images.
• handlers in the Python code take these simple commands from the views, as HTTP calls, and then make modifications to data = models. Django calls a route dispatcher to route the call to a correct piece of code. Note, here through the execution of a handler code, we are making changes to living models, that is, objects. (The models are abstracted as python-language Classes. Classes are code blueprints. When you instantiate a Model in your live server, you make a new living object, that can actively hold data, and let it be played around with.) If we were programming a game backend, different kind of objects would be living there: perhaps player positions, bullets flying in the world, and so on. Or just kittens flying around!
• models-based Objects can and should be “persisted” (saved) to whatever real backend (=”database”) choice you have — Django even offers a simple real persist layer to be your batteries-included, default backend. In simplest of these, we can just use a dump- a single file that has the object data dumped into some format that allows the app to read that data back in, and instantiate objects based on this initializion data. The initilization now comes from the last time your web app shut down gracefully. So your app saves the state. Even though it would crash, or be gracefully shut down, it saves the data for you so you are good to go, next time again.

Do the backend!

But first do the backend logic.

This is the magic of making a raw, fully functional web app, as soon as possible; try and use the default views as much as possible. So, don’t yet concentrate on the looks (frontend) of the app. Everything works in your app nevertheless - even though you would not be satisfied with the aesthetics at this point. Keep on churning the backend logic until you get a working app.

Constant iteration is they key. Run the app. Make changes, test them immediately.

There shouldn’t be such a small addition, that running the iteration and really testing you made a good work, could be bypassed.

This is true agile and iterative style. I have at times hacked 150 lines of code, out of my head, without running in between — without using any kind of tutorial, without using ChatGPT — and lo and behold: it worked. These kind of things are not professional programming. I repeat: NOT. That is hacking. Hacking is not a good way to do code.

In fact, before starting iteration, it is really good to just back one more step: make a iterative loop you can always run, and shutdown.

Logic programming into a backend

The C (controller) is where part of your UX is built. Controller plane is about programming functionality through the links and buttons in the web page. So stay calm, and still wait for the full inspiration of going to CSS. We can work with default link looks, and we can work with plain old boring web buttons. As long as you get to do through the frontend, what needs done, we’re good. Believe me, it serves you well to go this route. You will get the backend done in no time.

Django is thus a full MVC framework— model, view, controller.

Django is quite a classical, complete full-stack app. It is one of the easiest perhaps to take for a test-drive. If you have python already setup, then Django is a “pip install” away from you. How to Install Django & Setup. Step 1: Install Pip | by Hariharan | Medium

What does Django bring to table?

I am out there to learn and improve my skills with Django. So far it seems very enticing, especially I like the separation of app development architecture, from the actual “beef”: the artefacts creation. This is a important point. Django allows you to basically develop the app’s logic in manageable pieces. I try to utilize this, by defining the features in terms of MVT:

Plan of the system: Models

• child
• parent
• ticket

Have children. Every child has a web page — their personal view, rendered as a route. Players can view their time bank using a browser.

Tip: if you can’t make a living page in Django quite yet, make a simple HTML page in your Sublime Text or similar editor. Save, and load that page right into your browser to see the effect. Tune the page source code, and try and use Django model data injected into the page as soon as possible. When you inject the Django data, instead of using manually crafted HTML, you are there! The Proof of concept works. You can later work on the Model finessing, making better looking views, and using the data in a more rich way. But getting the first glimpse of your view, even as a mockup, is really inspiring.

Routes

Django creates routes to your views. To add a view, all you need is tell Django that you want a new view. The view is personalized, in the sense that its data comes from the live object (model) particular to a unique player.

Templates

Pages (views) can have templates. These allow you to keep the app’s various views adhere to standards, and also helps you organize your code, again in the Django OO programming style.

Templates are something you don’t need to include in your very first iterations. Django is also very flexible in the way that it allows you to catch up later, and start using templates later on.

Django keeps your app as a internal model, and the artefacts (anything that is actual payload code, data) can be generated.

So this is one of the most powerful features of Django, indeed. It is versatile, and Django allows you to work on any level of abstraction and architecture of your web app, holding the reins — and still allowing you to hone your coding skills in making adjustments to any artefacts manually, if needed.

One of the most powerful ways of benefiting from Django is actually to familiarize with the powers it holds. You are investing in future ease of app maintenance.

Read about Django architecture and best practises here:

Django Project Structure: A Comprehensive Guide | by Julio Cesar Siles Perez | Django Unleashed | Medium

Admins are parents, who can create time tickets. Authentication and security shall be baked into the app to prevent tricking the system, by other kinds of accounts.

Code is given, which can be mailed, sent via Whatsapp, or just drawn on a piece of paper.

Codegenerator is a function that does the string for a code. The string represents a pointer to data. We can estimate easily a length for the code: each code is single-use, so it gets generated, and possibly redeemed by a child account, in the view (page) — later on. A few usability design issues here can be dealt with later.

Children are users who can:

1. view time allocation for a week
2. redeem a ticket by entering a code
3. system shows that a ticket was validated and the time (bounty) is added!

Logic of the Time bank

Time bank allocates the time, based on a registered entry in the database. [F1]

Features-to-build:

So master db, the database shows ticket types for parents, and parents can click to designate the code for any of the registered children.

Children redeem the codes. When redeemed, the code adds time to child directly. Time configuration and summation rules are not yet in the plan. By default, the time is usable during a set fixed date.

System rules for time

1. Time unused on a date, is not accumulated, meaning that the time can be only used on that date.
2. Time is cleared — yet historical view of the accumulated maximum play times, by date, is always accessible to all parties

Problem points needing design — to solve:

Time spend chunk is marked by parent clicking on..?

Does the “time spend” need explicit marking?

Basically to have an effect, the idea is that children in the family earn time by doing chores. Chores apart, how we represent this is that Time Tickets are granted by parents; and redeemed by children.

But we might be missing one thing? In order for the time (limits) to be effective, we need to also have a control mechanism, so that the time limit has an effect. Here comes a real world problem: how would you best see this resolved?

I am really looking for an idea. Let me know!

And have a Great New Year 2024!!