299 |
|
|
300 |
\subsection{Konceptuella modeller baserat på objekt} |
\subsection{Konceptuella modeller baserat på objekt} |
301 |
|
|
302 |
a |
När man utgår från ett objekt så tar man ett objekt som |
303 |
|
användaren kan relatera till, en bok, kaffe bryggare |
304 |
\section{Värdet av MDI} |
eller dyl. Och sedan så gör man sin modell så att den |
305 |
|
liknar det fysiska objektet. Det bör även gå att |
306 |
Det kanske kan verka abstrakt, och som något som bara tar |
manipulera objektet på ett vis som liknar det fysiska |
307 |
tid att hålla på med MDI, och allt man kan göra inom detta |
objektet. Men man bör även tänka på vilka funktioner en |
308 |
(mock-ups osv), men faktum är att den tid (och de pengar) |
användare kan tänkas önska utöver dom som finns i det |
309 |
man lägger ner på MDI tjänar man igen ganska så fort. |
verkliga objektet. Om man gör en ordebehandlare kan det |
310 |
Dessutom så är det med hjälp av en mock-up lätt att tidigt |
vara väldigt trevligt om denna klarar av att t.ex. |
311 |
fånga design fel, eller till och med logik fel, och ju |
kompilera texten, rättstavning osv. |
312 |
tidigare man kan hitta fel, desto billigare blir dom att |
|
313 |
avhjälpa. |
\subsection{Interface metaforer} |
314 |
|
|
315 |
En annan viktig sak att tänka på med MDI är att man kan på |
Denna metod går ut på att man tar och försöker efterlikna |
316 |
ett sätt använda det som en reklam tavla för sitt företag, |
en välkänd metod, eller något som användaren känner igen |
317 |
om man gör en extraordinär lösning på något så kommer |
för att manipulera systemet. Det handlar oftast om att man |
318 |
detta att sprida sig, men det kommer ännu mer att sprida |
försöker abstrahera bort hur datorn gör, och istället |
319 |
sig om man gör dåliga MDI lösningar. Ett företag som |
likna det vi något som man känner igen. Dock så är boken |
320 |
tidigare har köpt en produkt som kanske är bra, bara det |
vi har väldigt kritisk mot denna metoden att utveckla |
321 |
att de inte kan nyttja den kommer inte att köpa en produkt |
produkter, så vi tänker inte gå in på denna så djupt. Dock så |
322 |
till av samma företag som den förra. |
tror vi att det borde vara en bra metod att iallafall |
323 |
|
fundera på, men man måste nog vara försiktig så att man |
324 |
|
inte gör ''hål`` i designen då man använder metaforer. |
325 |
|
|
326 |
|
\section{Värdet av MDI} |
327 |
|
|
328 |
|
Det kanske kan verka abstrakt, och som något som bara tar |
329 |
|
tid att hålla på med MDI, och allt man kan göra inom detta |
330 |
|
(mock-ups osv), men faktum är att den tid (och de pengar) |
331 |
|
man lägger ner på MDI tjänar man igen ganska så fort. |
332 |
|
Dessutom så är det med hjälp av en mock-up lätt att tidigt |
333 |
|
fånga design fel, eller till och med logik fel, och ju |
334 |
|
tidigare man kan hitta fel, desto billigare blir dom att |
335 |
|
avhjälpa. |
336 |
|
|
337 |
|
En annan viktig sak att tänka på med MDI är att man kan på |
338 |
|
ett sätt använda det som en reklam tavla för sitt företag, |
339 |
|
om man gör en extraordinär lösning på något så kommer |
340 |
|
detta att sprida sig, men det kommer ännu mer att sprida |
341 |
|
sig om man gör dåliga MDI lösningar. Ett företag som |
342 |
|
tidigare har köpt en produkt som kanske är bra, bara det |
343 |
|
att de inte kan nyttja den kommer inte att köpa en produkt |
344 |
|
till av samma företag som den förra. |
345 |
|
|
346 |
|
|
347 |
\end{document} |
\end{document} |