BSEB Inter Multimedia & Web Tech common mistakes
BSEB Inter Multimedia & Web Tech · Understand the traps and how to avoid them.
Treating lossy and lossless formats as interchangeable, so the candidate saves a photo as JPEG for a logo with flat colours or saves audio as MP3 when the task specifies an uncompressed master, and then cannot explain the visible ringing or generation loss.
The syllabus names formats (JPEG, GIF, PNG, WAV, MP3, MP4) without emphasising the compression trade-off, so candidates memorise file extensions and never link each format to its compression type, colour support, or transparency behaviour.
What to do instead
Build a one-page comparison table with columns for compression type, transparency, colour depth, typical use, and one drawback. For each format, write one sentence explaining what artefact appears if it is misused (JPEG blocking around sharp edges, GIF banding at 256 colours, MP3 pre-echo). Practise justifying a format choice in two sentences for five different asset types.
Confusing resolution, pixel dimensions, and physical print size, for example answering that doubling the DPI of a 600x400 pixel image makes it print larger, or claiming that increasing DPI adds detail to an existing bitmap.
DPI, PPI, and pixel count are taught as vocabulary rather than as a relationship, and candidates never compute the arithmetic linking pixels, resolution, and inches.
What to do instead
Drill the formula print size in inches = pixels / DPI in both directions until it is automatic. Work five problems: a 3000x2000 image at 300 DPI, the same image at 150 DPI, the DPI needed for a 6-inch-wide print from 1200 pixels, and what happens to file size when only DPI metadata changes. State explicitly that resampling up cannot create real detail.
Describing the RGB and CMYK colour models as two names for the same colours, or claiming that a monitor displays CMYK and a printer uses RGB, and failing to explain why a bright on-screen colour may print dull.
Colour models are memorised as abbreviations without the additive-versus-subtractive principle, and candidates have no mental model of gamut, so the conversion problem looks like trivia rather than physics.
What to do instead
Learn the two models as opposite processes: RGB adds light, CMYK subtracts light with ink. Draw the primary and secondary colours for each. Then explain in three sentences why saturated RGB blues and greens fall outside the CMYK gamut and what a designer does about it (soft-proof, choose a printable substitute, or accept a shift).
Mixing up frame rate, bit depth, and bit rate when calculating file size or judging quality, so the candidate answers that a higher frame rate improves colour accuracy or that bit depth controls smoothness of motion.
All three are numbers attached to digital video, and revision notes list them side by side without showing which property each one governs.
What to do instead
Attach each term to a single question it answers: frame rate, how many images per second; bit depth, how many shades per channel; bit rate, how many bits per second of data. Then compute an uncompressed video size (width x height x bit depth x frame rate x duration / 8) for a short clip and compare it with a compressed version at a stated bit rate. Explain the result in words.
Treating frame-by-frame animation and tweened animation as the same technique, or claiming that a higher frame rate always makes an animation look better, without discussing file size, motion blur, and the persistence-of-vision principle.
The animation unit introduces several techniques quickly, and candidates learn the labels without seeing a worked example of how each one is authored or what it costs in file size.
What to do instead
For each technique (frame-by-frame, motion tween, shape tween, onion skinning, keyframe versus blank keyframe), write what the animator actually does and one situation where it is the right choice. Then compare a 12 fps and 24 fps version of the same 3-second loop in terms of frames, file size, and perceived smoothness, and state when 12 fps is acceptable.
Writing HTML with unclosed tags, block elements nested inside inline elements, or multiple h1 elements on one page, and treating the page as valid because the browser still renders it.
Browsers silently repair malformed markup, so candidates never receive an error signal and conclude that correctness does not matter. Many also learn layout from copying snippets rather than from the content model.
What to do instead
Validate every practice page with the W3C Nu HTML Checker and fix all errors before moving on. Memorise the nesting rules that matter: only li inside ul or ol, only td and th inside tr, no block-level element inside a or span, one main landmark and a sensible heading order. Write one page from a blank file with no copying and validate it.
Using tables or divs for page layout and omitting alt text, labels, and heading structure, then arguing that the page looks correct so accessibility is satisfied.
Visual correctness is the only feedback candidates get in a browser, and accessibility is often taught last as a checklist rather than as a design constraint that shapes markup choices.
What to do instead
Refactor one existing page: replace the layout table with semantic elements (header, nav, main, footer), add a text alternative to every image and decide when alt should be empty, associate every input with a label, and confirm the heading outline is sequential. Test with the keyboard alone and with a screen reader or accessibility checker, and record what failed.
Confusing CSS selector specificity and the cascade, so the candidate adds !important or inline styles to force a rule, or cannot explain why a class rule beats an element rule but loses to an ID rule.
Specificity is a four-part score that is rarely written out, and candidates debug by trial and error in the browser instead of reasoning about which declaration wins.
What to do instead
Learn the specificity score as (inline, ID, class/attribute/pseudo-class, element/pseudo-element) and compute it for ten selectors, including descendant and compound ones. For three broken stylesheets, predict the winning declaration on paper before testing. Practise fixing conflicts by lowering specificity or reordering source, and reserve !important for genuinely exceptional cases with a written justification.
Treating client-side and server-side scripting as the same thing, for example claiming JavaScript can write to a database directly, or that a form's required attribute removes the need for server-side validation.
Both are called scripting and both appear in the same chapter, and candidates rarely see a request-response cycle drawn out, so the boundary between browser and server stays abstract.
What to do instead
Draw the request-response cycle once with browser, network, and server clearly separated, and place each task on the correct side: DOM updates and instant feedback in the browser; authentication, storage, and trust decisions on the server. Then explain in writing why client-side validation improves usability but server-side validation is mandatory, and give one concrete attack that bypasses the browser entirely.
Describing publishing as dragging files to a host, with no mention of domain name registration, DNS records, FTP or SFTP transfer, directory structure, relative versus absolute paths, or testing after upload, and no awareness of copyright and image licensing in project work.
Publishing and ethics sit at the end of the course and are often covered in a single lesson, so candidates answer from vague memory and skip the steps they have never performed.
What to do instead
Write a numbered publishing checklist and follow it once for a real small site: register or configure the domain, note the A or CNAME record and propagation delay, upload via SFTP preserving folder structure, set index.html as the entry point, verify relative links and case-sensitive filenames on the live server, and test in two browsers. Add a sources list recording the licence of every image, font, and audio clip used, and state the permission needed for each.