Users judge an extension by its pages. A well-designed page has the fields in the order the job is done, the actions where the hand goes, a FactBox that answers the next question, and views that replace three saved filters. The conventions Microsoft uses, how the action bar works since version 20, and the ten things that make a page feel professional.
Nobody sees your codeunits. Everybody sees your pages. A card with forty fields in the order they were added, a list with no views and an action hidden under "More options", is an extension users will describe as clunky however good the logic is. Page design in AL is mostly conventions, and Microsoft's own pages are the conventions written down. Follow them and your page looks like it belongs.
Group fields into group sections named for what they are (General, Shipping, Invoicing, Courier), in the order the user does the job: identity first, then the things they fill in, then the things the system fills in. Within a group, the most-used fields at the top. Use Importance = Additional for the fields most users never need (they collapse under "Show more") and Importance = Promoted for the one or two that should be visible when the FastTab is collapsed. Set ShowMandatory = true on required fields so the red asterisk appears. Every field has a ToolTip in Microsoft's form ("Specifies the..."), because the analyser insists and because the tooltip is the only documentation most users read.
A list page should open to what the user needs today. Views (defined in the page under views, with filters and sort order) replace the saved filters every user used to maintain: "Open", "Overdue", "Mine", "Awaiting despatch". Put the five that cover most of the day in the page; users add their own on top. Set the table's DropDownFieldGroup and Brick field groups so lookups and the phone client show the right four fields rather than the primary key and whatever came next. Use Editable = false on list pages where editing in the grid is not intended, and a card for the detail.
The action bar has three areas. actions { area(Processing) } is the full list under the "Actions" menu; area(Navigation) under "Related"; area(Reporting) under "Reports". Since version 20, what shows on the bar itself is defined separately in actions { area(Promoted) { group(Category_Process) { actionref(Post_Promoted; Post) } } }, which is the promoted layout: named groups (Process, Report, New, Category4 to Category20) with actionrefs pointing at the real actions. Put the two or three actions a user needs most as direct promoted actions, the rest in named groups, and leave the long tail in the menus. For page extensions, addlast(Processing) and addlast(Category_Process) place your actions alongside Microsoft's rather than in a "CON" group nobody opens.
Every action has an Image (from the standard list; the wrong image looks worse than none), a ToolTip, and where appropriate a ShortcutKey. Actions that run a report use RunObject; actions that need logic call a codeunit, not inline code in the trigger.
The panel on the right exists to show the user what they would otherwise open another page for: the customer's balance and credit limit while entering an order; the item's stock by location while adding a line; the document's attachments; your extension's shipment status. A FactBox is a CardPart or ListPart page with SubPageLink to the main record. Add it to standard pages with a page extension (addlast(FactBoxes)). Keep each one to a handful of fields; a FactBox that needs scrolling has become a page.
If your extension is a whole feature area, give it a role centre or, more often, add cues (the tiles with counts) to an existing one: "Shipments awaiting labels: 12", drillable to the filtered list. Cues are a CueGroup on a CardPart, with a table that holds FlowFields for the counts, and they are the most-clicked thing on most users' screens. Add a Headline part if there is something worth saying. And add your main list to the navigation menu (actions { area(Sections) } on the role centre, or the Navigation area of the relevant standard role centre via a page extension) so it is one click away, not a search.
A page that stops the user with a modal for everything is exhausting. Confirm for a decision; a notification (the blue bar, with actions) for something they should know and may act on; a Message only for completion of something they asked for. Progress dialogs for anything over a couple of seconds. See the error handling post for errors.
Nothing heavy in OnAfterGetRecord or OnAfterGetCurrRecord on a list; FlowFields with SIFT keys for counts and sums; SetLoadFields in any code the page runs; and no CalcFields on every row (the performance post). A page that takes two seconds to scroll is a page users avoid.
None of it is hard. It is the difference between an extension the business is proud of and one it tolerates, and it costs about ten per cent more at build time. If you have a page users complain about, send us a screenshot; it is usually two of the ten.
