Frontend for Enterprise Inventory Management app

Questions I've had on the job:

• What is the actual source of this dependency?
• Is this package public, private, or internal-only?
• Which registry should this project install from?
• Does the project need an auth token or .npmrc setup?
• Is the issue caused by code, permissions, network, or registry configuration?
• Is a blocked install a local problem, or an intentional device/security policy?

Useful reminders:

• An artifact repository stores build outputs and packages:

  • npm packages
  • Java packages
  • Docker images
  • binaries
  • release bundles

• If node_modules is deleted, reinstall with:

npm install

• Do not use npm update just to restore deleted dependencies.
• npm install restores from package.json and the lockfile.
• npm update attempts to update dependency versions within allowed ranges.

If npm install fails with E401:

• check the registry
• check auth
• check .npmrc
• check whether a private package source is required
• ask the team what install path is approved

If a browser warning comes from dependency code:

• upgrading npm itself usually will not fix it
• identify the package that emits the warning
• check whether that package has a safe upgrade path

Search example:

rg "-ms-high-contrast" node_modules

2. Search, filters, and status language

Wildcard search:

• use * as the main signifier
• put the cue close to the input
• explain it with a tooltip or helper line
• provide one short example

Possible microcopy:

• Supports * wildcard search
• Use * to match any characters
• Example: ABC*

Avoid:

• inventing a custom wildcard icon
• relying on color alone
• placing the explanation only in documentation

Status filter naming:

• Default is usually not a good user-facing label.
• If the states are time-based, name them like time states.

Better trio:

• On Track
• Due Soon
• Past Due

Multi-select behavior:

• label the dropdown Due Status
• if all are selected, show All due statuses
• if none are selected, show No due status filter
• if one is selected, show the selected label
• if multiple are selected, show labels or a count

Avoid making All behave like both a status and a command.

3. Notifications, loading, uploaders, and tags

Notification dropdowns should help users triage. Useful notification properties:

• type
• title
• short description
• timestamp
• read/unread state
• source or context
• action, if available

Common notification types:

• informational
• warning
• error
• approval needed
• reminder
• mention or assignment

Expected controls:

• mark as read
• dismiss
• view details
• view all
• notification settings

Uploader states to design:

• empty
• drag over
• file selected
• uploading
• uploaded
• invalid file type
• file too large
• upload failed
• disabled

Uploader features to specify:

• accepted file types
• max file size
• single or multiple files
• remove or replace file
• retry failed upload
• cancel upload
• success message
• error message

Status tag structure:

<span class="app-tag app-tag--success">
	<span class="material-icons" aria-hidden="true">check_circle</span>
	<span>Allocated</span>
</span>

Tag rules:

• one base class
• modifier classes for status
• icon plus text
• do not rely on color alone
• short labels

4. Affordance and semantic UI structure

Affordance:

• what an element makes possible

Signifier:

• how the UI communicates that possibility

Examples:

• button shape suggests click
• drag handle suggests reorder
• underline suggests link
• chevron suggests expand
• disabled style suggests unavailable action

Questions to ask:

• Can users tell what is interactive?
• Do icon-only controls have accessible names?
• Is the action obvious without reading documentation?
• Are important actions visible without hover-only discovery?

Topbar app name:

• a persistent app shell usually should not own the page h1
• the route or page content should usually own the h1
• the topbar app name can be a link inside a header

Example:

<header class="app-topbar">
	<a class="app-name" href="/dashboard" aria-label="Go to dashboard">
		Application Name
	</a>
</header>

Use headings for structure, not visual styling.

5. Embedded reports and authentication

When an app embeds multiple secure reports, users usually expect one login session to cover all reports from the same provider.

But behavior depends on:

• authentication method
• report provider domain
• iframe settings
• browser cookie rules
• third-party cookie restrictions
• organization SSO policy
• session timeout rules

Questions to test:

• Does report A require login?
• After logging into report A, does report B load without another prompt?
• Are both reports from the same provider and tenant?
• Are iframes lazy-loaded only when their tab is opened?
• What should users see if authentication is required again?

6. Performance, CSS, and rendering

When a web app feels sluggish, likely causes include:

• too much framework rerendering
• large DOM trees
• heavy tables
• nested scroll containers
• expensive CSS layout recalculation
• resize or scroll listeners firing too often
• animations triggering layout
• too many active subscriptions
• development build overhead
• recent dependency or stylesheet changes

Investigation path:

1. Record the slow interaction in browser DevTools.
2. Look for long scripting, layout, paint, or style recalculation.
3. Use framework dev tools to see which components rerender.
4. Compare before and after recent CSS or component changes.
5. Test a production build before blaming runtime performance.

Useful rendering terms:

• layout / reflow: browser recalculates size and position
• paint: browser redraws pixels
• compositing: browser combines layers, often cheaper than layout

CSS reset issue:

:root {
	font-size: 62.5%;
}

Why teams used it:

• easier mental math
• 1.6rem feels like 16px

Problems it can create:

• smaller default text
• accessibility and zoom surprises
• mismatch with third-party components
• confusion when using docs or examples
• broken assumptions in rem-based spacing
• inconsistent sizing across apps
• media query confusion when breakpoints use rem

Better default:

html {
	font-size: 100%;
}

Then use design tokens for:

• font sizes
• spacing
• radius
• component dimensions
• breakpoints

7. Scrolling and custom scrollbars

Scrollable regions need to be obvious and usable.

Common problems:

• hidden scrollbars
• nested scroll areas
• keyboard focus moving into content that is not visible
• horizontal scrolling at zoom
• scroll traps inside drawers or modals
• inconsistent behavior between mouse, keyboard, and trackpad

Design handoff should specify:

• which region scrolls
• max height or viewport behavior
• whether the page or panel owns scroll
• empty, loading, and overflow states
• expected keyboard behavior

Relevant accessibility areas:

• focus visible
• focus order
• reflow at high zoom
• keyboard access

Custom scrollbar patterns:

.scrollable::-webkit-scrollbar {
	width: 8px;
}

.scrollable::-webkit-scrollbar-thumb {
	background: #999;
	border-radius: 4px;
}

.scrollable {
	scrollbar-color: #999 transparent;
	scrollbar-width: thin;
}

Avoid global universal scrollbar styling when possible:

* {
	scrollbar-width: thin;
}

Prefer scoped classes:

• .scrollable
• .table-scroll
• .drawer-content
• shared scrollbar utility
• shared scrollbar mixin

8. SVG assets and generated text

SVG options:

1. External SVG file

   • best for illustrations
   • keeps templates cleaner
   • use with img

2. Inline SVG

   • best when styling SVG parts directly
   • useful for small icons or dynamic color
   • can bloat templates

3. Icon library

   • best for standard UI actions
   • avoids maintaining custom path data

Watch for:

• duplicate SVG id attributes
• clipPath or mask collisions
• broken use references
• unsafe dynamic SVG injection
• huge inline path data in templates

Angular asset path reminder:

<img src="assets/images/example.svg" alt="" />

Use the assets/ path as a public app path, not a deep relative path from the component folder.

Generated text with bold keywords:

• possible, but avoid unsafe HTML injection
• safer to render structured text parts in the template
• use [innerHTML] only with trusted strings and careful sanitization

Questions to ask:

• Is the source string user-generated?
• Are keywords controlled by the app?
• Does the text need translation later?
• Would a structured array be cleaner than HTML in strings?

9. Internal systems, acronyms, and exports

Enterprise apps collect acronyms quickly.

When a system name is unfamiliar, ask:

• Is this an industry term or internal shorthand?
• Is it a database, API, service, report, or team-owned platform?
• Is it the source of truth?
• Is it read-only?
• How often does the data sync?
• Who owns schema or field changes?

Public writing habit:

• do not publish internal system names
• describe the role instead
• use terms like internal data source, source-of-truth system, or reporting platform

Bulk export questions:

• What is the source-of-truth planning tool?
• Does the UI expose export?
• Can I filter by epic or parent item?
• Are all fields included?
• Do I have permission to export?
• Is the export allowed for the intended use?

Common export paths:

• export current filtered view as CSV
• filter by epic, then export child stories
• use the underlying issue tracker query language
• request API access
• ask a project admin for a report

What I want to keep practicing

• Turn vague friction into specific questions.
• Separate UX expectation from technical constraint.
• Ask whether a term is internal or industry-wide.
• Prefer public-safe language in notes.
• Document the decision, not the private context.
• Use checklists when the topic will come back.
• Keep commands short and explain what they do.
• Treat accessibility concerns as design requirements, not afterthoughts.