5 exercises — learn when fragments are acceptable and when complete sentences are required in technical documentation, UIs, and error messages.
0 / 5 completed
1 / 5
Which statement about sentence fragments in bulleted lists is correct?
Technical documentation widely accepts fragment bullet points — provided all items in the list are grammatically parallel. Example of acceptable fragments: "• Improved query performance / • Reduced memory usage / • Fixed authentication timeout" — noun phrases, parallel. Unacceptable mix: "• Improved query performance / • The authentication timeout was fixed" — mixes fragment with full sentence, breaking parallelism. The key rule is consistency and parallelism within a list, not whether each bullet is a complete sentence. Style guides (Google, Microsoft, Apple) all permit fragment bullets.
2 / 5
Which is the most appropriate error message for a production application?
"The requested file was not found on the server." is the most appropriate for a production error message. It is a complete sentence with subject, verb, and context — it tells the user what happened and where. Option A ("File not found.") is a standard, widely-recognised fragment acceptable in many contexts (HTTP 404 messages, log output, mobile notifications) but lacks the politeness and detail expected in a polished application UI. Option C is fragmented and unclear. Option D is overly wordy and informal ("at this time" is filler). For user-facing errors, prefer complete, concise sentences; for log files and developer tools, shorter fragments are acceptable.
3 / 5
Which use of a fragment is most appropriate in a user interface?
"Save changes" is the correct imperative fragment for a UI button label. UI microcopy (labels, buttons, menu items, tooltips) universally uses imperative verb phrases or compact noun phrases — never full sentences. Full sentences on buttons are verbose and visually cluttered. Standard patterns: "Save changes", "Delete account", "Run tests", "View report". These are not errors; they are the expected and professional style for interface labels. Option C ("Changes saved when you click here") is a confusing mix of present and future. Option D uses a gerund phrase, making the label sound nominal and vague.
4 / 5
A developer is writing step-by-step installation instructions. Which approach is most appropriate?
Both imperative fragment steps (Option A style) and complete-sentence steps (Option B style) are used in professional technical documentation — the choice depends on context. Fragment steps ("Open terminal", "Run install command") are common in quick-start guides, CLI documentation, and developer-facing READMEs where brevity is valued. Complete-sentence steps are preferred in formal user manuals, enterprise documentation, and content aimed at less technical audiences. Option C (mixing both) breaks parallelism and is always wrong. The consistent application of one style throughout a document is the critical rule.
5 / 5
Which passage is most appropriate for the body text of a formal technical specification document?
Formal technical specification documents (RFCs, SRS documents, architecture specs) require complete sentences. Option B is correct: one coherent sentence with clear syntactic relationships between subject ("the system"), verb ("shall authenticate"), object ("all API requests"), and modifiers ("using OAuth 2.0 before processing them"). Option A contains unacceptable fragments in formal prose — "Using OAuth 2.0." and "Before processing." are dangling modifiers that lack a main clause. Option C is appropriate for a bullet list but not for body prose. Option D — a series of em-dash fragments — is suitable for informal notes, not specification documents.