3

I'm not conversant with this topic, and therefore I watched a tutorial about a one-page dynamic PHP website (quite educational in my opinion) in which the creator designed the following pages.

Enter image description here

For each and every ADD, DELETE and EDIT page, there are two additional files to create, making two per page. In other words, (1*2)3 = 6 subpages or (33) = 9 pages if we consider ADD, DELETE and EDIT as well.

I repeated the process for a potential project, leaving me with this:

Enter image description here

By way of counting, we have:

  • 7 ADD pages (7*3 = 21).
  • 7 DELETE pages (7*3 = 21).
  • 3 UPDATE pages (3*3 = 9).

Making a total of 51 pages to cover all of ADD, DELETE and UPDATE in the design. In my opinion, this is a considerable amount of pages to design, even if most of them are sufficiently generic in their structure that I could copy and paste them with minimal modifications required most of the time.

Perhaps I'm focusing too much on the number to see the bigger picture, which brings me to you. Are there alternatives to this scenario or should I devote myself to creating each page? Perhaps I made a mistake?

4
  • 6
    For most software systems, a crud based UI leads to a poor user experience. A better approach (imo) is to design task based UI’s.
    – Rik D
    Feb 19, 2023 at 16:00
  • if these are staff/admin only screens that end users do not see this is fine. However, I suggest you can auto-generate most of these pages/code by pointing a tool are your DB so you should not have to make 51 pages. They can be fully automatically generated. Leaving you time to focus on the customer facing pages.
    – Daveo
    Feb 20, 2023 at 3:31
  • "...i could copy and paste them with minimal modifications..." Ya, when that happens to me I hear a voice in my head: "Refactor!". Feb 21, 2023 at 12:47
  • 1
    This exercise is a great exercise, especially when starting out. It helps you see the big picture without committing to writing lots of code. The next step is to find ways to reduce it by factoring out the common parts. Eventually, you'll find several operations can be grouped on a single page.
    – user148298
    Feb 21, 2023 at 20:58

2 Answers 2

14

It appears that this design is based on a CRUD model. This kind of model is good for designing database operations, and might actually work for small website UI, but when you are designing for a user of a larger system, it's better to model your user interfaces by focusing on business processes and use cases.

You wouldn't, for example, ask a user to write an invoice by creating an invoice header record, creating an address record, creating line items with the subtask of doing a lookup on a part number, even though that's what actually happens under the hood when you order a product.

Focusing on CRUD is easier when you're first learning how to build a website. But beginner projects and examples always tend to be a bit naive. Keeping things simple makes it easier to learn the basics. Once you know the basics, you can get more sophisticated with your approach.

1
  • 2
    seconded. for a simple tutorial all the Add,Edit,Delete backend pages might be the same, tbu they will soon diverge as more real life business logic is added.
    – Ewan
    Feb 19, 2023 at 19:02
4

Making a total of 51 pages to cover all of ADD, DELETE and UPDATE in the design. In my opinion, this is a considerable amount of pages to design, even if most of them are sufficiently generic in their structure that I could copy and paste them with minimal modifications required most of the time.

Right, but I would dare to say that it depends a lot on the complexity of the business process you are easing through this application. However, in today's applications, most of the CRUD operations are (or can be) arranged in no more than 2 pages (list view, edit view).

In my experience, this is a design concern you address based on the end user's skills, knowledge and current methodology. If the end user is actually doing its job in X way, your application mimics X but in a user-friendly way. In other words, simpler and faster so users can be more productive.

Take this page we are now as an example. From this page users can add, edit, remove, upvote, downvote, share, follow and flag answers. But also add, edit, remove, flag and upvote comments. All on a single page.

Another example is CRUD tables. A CRUD table renders a list of records and, at the same time, allows you to edit, remove or add records directly over the table. Know think of pages rendering one or more CRUD tables. That's a lot of CRUD operations per page.

Are there alternatives to this scenario or should I devote myself to creating each page?

If you are in the early stages of conceptualization, don't approach the design from the bottom up. Instead, do it from a top-down.

Instead of drawing each CRUD operation per entity or page, draw workflows or transitions from page to page. Then, you draw more concrete diagrams about what procedures are supported by each page. Later, draw activity diagrams describing those operations and how they correlate with each other.

Go from an abstract idea, down to concrete details by zooming in on every design iteration.

Not the answer you're looking for? Browse other questions tagged or ask your own question.