Is this approach to website design adequate or am I making a mistake?

Question

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.

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:

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?

Answer 1

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.

Answer 2

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.