CRUD page design



  • CRUD page. A list of items. Add/edit item. Delete item. It's basically a GUI for an SQL table. What could be simpler, right?

    What I've come to realize is that every developer (or company) seems to have a slightly different way of arranging this. How do you display multiple items (table, list view?), details about each item (popup, sidebar, separate page?), where do you perform edit (inline, popup, page?), etc. There is a surprising variation here.

    Here's for example the way I do it currently.

    The list view

    0_1514593100724_e1201769-1cc7-4971-b163-d5dc95cc8b38-image.png

    There is some kind of top bar or side bar with at least a New Record button and fuzzy search. There can also be other filters here. They all act directly on the URL of the page, so you can send the link to someone else and they will see the same data that you see.

    Then there's a sortable table of records (looking to transition to some kind of cards here, because of the mobile). And there's either pagination or load more button at the bottom.

    Right-most column are your usual Edit / Delete / View buttons, depending on requirements.

    The details view

    0_1514593400557_e2a460d2-1cc7-42ce-83ae-3cdfd097046f-image.png

    Always a tabbed page. First tab displays ALL the information about the item that couldn't fit into the table. It also has a sidebar, allowing you to go to Edit page or delete the record.

    Other tabs can show either other read-only data about the subject (eg logs, reports, charts) or offer commands you can perform against the record. Eg. uploading large files, starting or stopping some kind of background process, stuff like that. This is different than editing the record - an important distinction IMO.

    Delete dialog

    0_1514593671801_f5f67603-d9f1-4dac-a257-a4be10748f00-image.png

    Delete is shown in a popup. It can be in details or in list view - never in the edit view. The button label is always semantic ("Delete", not "Yes").

    Create / edit page

    0_1514593760507_4b8eb785-3620-4125-83d6-2b2a1aecdf01-image.png

    The same page and code is used both for edit and create actions. The only changes are if/else around a few labels.

    I always use a separate page for this, on its own url and everything. You enter the page, you make changes. If you click Save, the changes are saved, and you are sent back to the read page you came from (list or details). If you click Cancel, changes are discarded.

    Clear enter / exit workflow is important to me. I don't like inline editors or editing in a popup, stuff like that.


    Ok, so why am I writing all this?

    I am doing a little hobby project and I have to add some very simple CRUD functionality like this. So it's a chance for me to experiment a bit, try something new.

    Any comments on my current pattern, ways to improve it perhaps?

    What CRUD setup do you use in your projects? Is there some genius better way to put together these kind of apps?

    BTW, if you want to make wireframes like this, I used Pencil. It took me like 15 mins, pretty cool. I'm attaching my own thing, if you want to modify it.


  • And then the murders began.

    Overall it seems pretty well thought-out. However, I don't understand why you break editing into its own page - you're already breaking history/bookmarks with your tabs on the detail view, so you might as well just replace the General tab content with the Edit view via JavaScript instead of reloading the whole thing...

    (Although I also keep all the fields visible in the Edit view, even if they're not editable, so that the View/Edit views appear basically the same. Based on those mockups, you don't.)

    I personally try to stay away from tabs period, but your use of them makes sense. I'm used to seeing them for throwing random crap together that shouldn't be.

    Also, I usually have the list/detail on the same page stacked vertically, instead of separate pages; click a row on the grid to open the details in the bottom pane.


  • Notification Spam Recipient

    For the most part it looks exactly like the kind of stuff that's auto-generated by Entity Framework. 🤷🏻 It's alright, but I keep finding myself making things less simple as things like relationships start coming into play...



  • @unperverted-vixen said in CRUD page design:

    However, I don't understand why you break editing into its own page - you're already breaking history/bookmarks with your tabs on the detail view, so you might as well just replace the General tab content with the Edit view via JavaScript instead of reloading the whole thing...

    (Although I also keep all the fields visible in the Edit view, even if they're not editable, so that the View/Edit views appear basically the same. Based on those mockups, you don't.)

    If I understand you correctly, instead of going to a separate page, you propose to have the details page just turn into an edit page. Turn text fields into edit fields, stuff like that?

    A few reasons why I don't like this approach:

    • It will be hard to get 1-1 parity between each part of the view mode and edit mode. Eg. a details text should turn into a rich text editor, but maybe the text editor is better positioned to the full width of the page, instead of in its original little box.

    • If you don't keep 1-1 parity between the modes, it might be jarring when you transition between modes.

    • There could be parts of the details view that are only available for existing records. Eg. timestamps, list of log events, attached users/ownership, etc. So it might be awkward to reuse the same components for both edit and new page (presuming you will keep these fields on page, to maintain consistency).

    • Code complexity. You will have a lot of code and ifs/thens intermixed on this one page.

    • When you mention "reloading the whole thing", I presume you are thinking of typical server-rendered UI. I'm almost always using SPA-s these days, so page loading isn't a concern. It's instantaneous.

    @unperverted-vixen said in CRUD page design:

    I personally try to stay away from tabs period, but your use of them makes sense. I'm used to seeing them for throwing random crap together that shouldn't be.

    Yes, I always end up using tabs as secondary navigation. Sometimes I even orient them vertically and use them for the 3rd level of navigation as well.

    It just leaves you so many doors open. As the app keeps evolving, you always end up needing more information panes or special little sections attached to each entity, especially when you start adding related entities as well (eg. workers and projects, companies and departments...).

    @unperverted-vixen said in CRUD page design:

    Also, I usually have the list/detail on the same page stacked vertically, instead of separate pages; click a row on the grid to open the details in the bottom pane.

    Is this for desktop apps? This doesn't sound like it would work in a responsive web app.


  • And then the murders began.

    @cartman82 said in CRUD page design:

    • When you mention "reloading the whole thing", I presume you are thinking of typical server-rendered UI. I'm almost always using SPA-s these days, so page loading isn't a concern. It's instantaneous.

    Don't SPAs still need to do a call back to the server to (re)get the data? Or are you able to keep the initial model from the display mode around & reuse it?

    (I'm still very much in a 20th century web design mindset - SPAs are black magic that I know I should learn but that I haven't convinced myself are worth the benefit...)

    Is this for desktop apps? This doesn't sound like it would work in a responsive web app.

    Web app, yes; responsive, no.



  • @unperverted-vixen said in CRUD page design:

    Don't SPAs still need to do a call back to the server to (re)get the data? Or are you able to keep the initial model from the display mode around & reuse it?
    (I'm still very much in a 20th century web design mindset - SPAs are black magic that I know I should learn but that I haven't convinced myself are worth the benefit...)

    If you enter the edit mode straight from the details page, I think I just show you the same model that was already loaded before. Maybe I update it in the background, to keep you from editing stale data, can't remember 100%.

    Either way, since there is no full reload page cycle, the page change feels much less jarring than in a typical server-rendered application.

    @unperverted-vixen said in CRUD page design:

    Is this for desktop apps? This doesn't sound like it would work in a responsive web app.

    Web app, yes; responsive, no.

    Any kind of page or pane splitters are a big no-no in responsive apps.

    I'd work on slowly transitioning away from that pattern.



  • Here's a good post going through some of these CRUD edit patterns.

    BTW, Stack Exchange UX seems like a pretty chill community.


Log in to reply