Tag Archives: web

Mi lesz veled, Angular? Gondolatok az Angular Connect 2017 után

A héten volt szerencsém részt venni a Londonban rendezett két napos Angular Connect 2017 konferencián, ebben a blog bejegyzésben pedig néhány ott hallott gondolatot és benyomást jegyzek fel részint magamnak emlékeztetőül, részint mert másnak is hasznosak lehetnek.

Az itt leírtak közül több nem szó szerint így hangzott el az előadók szájából, ez már az én kivonatom. A fontosabb előadásokról videófelvétel készült, azok megtekinthetőek a konferencia honlapján, az tekinthető hiteles forrásnak.

Át kell állni Angular@latest-re

Tisztán látszik, hogy a Google nagyon komolyan veszi az Angulart. Nem egyszerűen egy szabadidőben készülő open source projektről van szó, hanem egy olyan technológiáról, amibe azért invesztálnak, mert ők maguk is használják. Az egyik legnagyobb projektjük, a Google Cloud Console több, mint 10 ezer TypeScript és 3 ezer Angular fájlt tartalmaz.

Ez nem újdonság, így volt ez már az AngularJS idején is, ám ebből rögtön két dolog is következik.

Az első, hogy a fejlesztés nem áll meg. Jó elvek szerint készült, és stabil alapokon áll már az Angular, ezért látványos új funkciókkal egyre ritkábban fogunk találkozni, viszont a motorháztető alatt folyamatos fejlesztések történnek minden verzióban. Itt a legfontosabb célterület a teljesítmény, aminek egyik összetevője az első oldalbetöltés ideje (Time To Interactive), a másik pedig az alkalmazás futása közbeni sebesség. Egyik területen sem muzsikál rosszul az Angular már most sem, de a csapat nem állt meg, minden verzióban egyre kisebb a bundle és egyre gyorsabb az app.

Ehhez az kell, hogy nagyon sok energiát öljön a fejlesztőcsapat abba, hogy a fordító egyre okosabb legyen. Csak egy példa: a Build Optimizer a TypeScript fordító sajátosságait és képességeit kihasználva tovább pofozza a kódot annak érdekében, hogy a minification még hatékonyabb legyen. Olyan trükköket csinál a kód variálásával, amivel egy átlagos projektben egy átlagos fejlesztő biztosan nem foglalkozna, Google méretekben viszont már sokat számít, mi pedig élvezhetjük a sok munka és kutatás eredményeit.

A második következménye annak, hogy a Google komolyan használja az Angulart, hogy a folyamatos upgrade-nek egyszerűnek kell lennie. A fejlesztő csapat szerint az Angular API stabil, nem várhatók breaking change-ek, a v4-ről v5-re történő átállás például a legtöbb projektnél egyszerű verzió szám átírás a package.json-ban, és máris új fordítót kap az app és gyorsabban fog futni. A Google alkalmazásainak eddig 25%-át migrálták át Angularra.

Adott tehát egy olyan keretrendszer, ami minden verzióban egyre hatékonyabb lesz, és a készítők szerint nem lesz nehéz az átállás az újabb verziókra. Tegyük még hozzá azt a tényt, hogy az Angular fejlesztők száma már meghaladja az AngularJS fejlesztők számát, és hogy az AngularJS-be valószínűleg már sokáig nem fog invesztálni a Google és máris ott tartunk, hogy az élő projekteket célszerű átmigrálni Angularra, és folyamatosan frissíteni a legújabb verzióra, azaz most v5-re.

Upgrade, de hogyan?

Kérdés, hogy mit kezdjünk a meglévő AngularJS kódbázissal, hogyan vigyük át Angularra?

Hogy upgrade vagy újraírás a jó megoldás, arra nincs egyértelmű, minden esetre működő válasz. A hivatalos álláspont szerint meg kell vizsgálni a kódbázis sajátosságait és a jövőbeli várható üzleti elvárásokat, és ezeknek a fényében kell dönteni. Ez egyáltalán nem új és nem meglepő.

Nincs meglepetés sajnos azzal kapcsolatban sem, hogy az upgrade-et hogyan érdemes kivitelezni. Nincs varázsszer, az ngUpgrade "az" eszköz, legfeljebb azt lehet variálni, hogy milyen lépésben haladunk. Ha az alkalmazásunk több "oldalból" áll, akkor érdemes lehet route-onként haladni.

Összességében tehát az upgrade területén nincs más lehetőségünk, mint időt allokálni rá, és végigcsinálni. Itt szerintem a legtöbb projektben nem a mérnöki, hanem a menedzsment oldal fogja a nehézséget jelenteni.

Mit kezdjünk a nagy kódbázissal?

A folyamatosan bővülő kódbázis egyre nagyobb kihívást jelent. Növekszik a repository mérete, növekszik a fordítási idő, egyre több csapat dolgozik ugyanazon a kódon, egyre nagyobb problémát okoz a függőségek kezelése. Mit lehet tenni?

A Google és a Facebook a monorepo híve, az alkalmazások és a library-k egyetlen nagy repository-ban vannak, míg az Amazonnál és a Netflixnél a microrepository-ban hisznek, ott minden független egymástól. Bármelyiket is valljuk, a választás feltételekhez kötött.

A Google részben nyilvánossá tette a saját fejlesztésű build eszközét, a Bazelt, aminek az erőssége, hogy a kód módosításai után csak azt fordítja újra, amire kihatással lehet. Ha nincs publikus API változás, akkor csak az adott komponenst, ha van, akkor pedig azokat, amik arra épülnek. Így elérték, hogy az edit-and-refresh élmény 2 másodperc alatt legyen. Ehhez persze az is kellett, hogy a kódot okosan szervezzék. Átlagosan náluk 1 package-ben 1 Angular modul van, 1 modul pedig átlagosan 1.5 komponenst tartalmaz. Ezzel nem csak azt nyerik, hogy gyors a build, hanem azt is, hogy tiszták az interfészek és dokumentáltak a függőségek.

Továbbá érdemes megnézni, hogy az Angular.io webhely buildeléséhez milyen megoldásokat választottak, és abból mit tudunk felhasználni. Ez az Angular alkalmazás náluk az állatorvosi ló, sok benchmark erre vonatkozik.

DRY vagy PRY?

A Don’t Repeat Yourself elv szerint üldözni kell minden kód duplikációt, ha valahol ismétlődő kódot találunk, akkor azt azonnal refaktorálnunk kell.

Ám ha ezt túl korán tesszük meg, lábon lőhetjük magunkat. A közös kódrészlet függőséget jelent, az interfésze contractként kezelendő, aminek a változásait csak megfelelő körültekintéssel és kommunikációval lehet elvégezni.

Ha van megbízható CI infrastruktúránk és jó teszt lefedettségünk, akkor ez költséges, de nem kockázatos. Kiszervezzük a közös kódot egy saját package-be, és ha bármi változik a package-ben, akkor újrafordítunk minden olyan alkalmazást és package-et, ami arra épül és újra is teszteljük azokat.

Ám ha nem vagyunk ilyen szerencsés helyzetben, akkor a túl korán alkalmazott DRY nem csak költséges, de kockázatos is lehet. Amíg tehát egy kódrészlet gyakran változik, addig inkább a Please Repeat Yourself (PRY) elvet érdemes követni, és csak a stabilizálódott kódokat kiszervezni közös helyre.

Mielőtt azonban vallást váltunk és elkezdjük követni a PRY elvet, érdemes feltenni magunknak a kérdést: vajon vissza fogunk-e térni később, és refaktoráljuk-e a már stabil kódrészletünket, vagy a jól működő dolgokhoz általában nem nyúlunk?

Zárójelben jegyzem meg, hogy a build eszközeink (TypeScript compiler, Angular compiler, Build Optimizer, minifier, Webpack stb.) nagyon agresszíven törekszenek a duplikáció kiszűrésére, “mutatványos környezetben” (production) tehát nem nagy a veszteség.

Hogyan teszteljünk nagy kódbázist?

A tesztelés terén nem tartogatott meglepetéseket a konferencia. Volt ugyan egy előadás a SerenityJS-ről, ami nem a Protractorban megszokott Page Objects elvet követi, hanem a Screenplay Patternt, de engem nem győzött meg.

Egyrészt azért, mert szerintem a Page Object módszert is lehet úgy használni, hogy a felsorolt problémákat elkerülje (kód mérete, olvashatósága, duplikációk stb.), másrészt pedig azért, mert nem látom, hogy ez miért jobb, mint a jól bevált Gherkin-Cucumber páros.

Ami viszont fontos – bár nem új – gondolat az előadásból, hogy a teszteket igenis tervezni kell. A jól megtervezett teszt esetekből lesznek a jól megtervezett teszt implementációk, azaz a karbantartható teszt kód.

Mi várható 2018-ban?

A fordító és a runtime folyamatos fejlesztésén kívül az Angular csapat természetesen újabb funkciókkal is bővíti a keretrendszert, amiből a PWA, az Angular Universal és az Angular Elements kapott nagyobb teret a konferencián.

PWA

A PWA, vagy teljes nevén Progressive Web Apps, a legújabb (?) név arra a jelenségre, hogy webes technológiákkal készített és az interneten hosztolt programkód olyan felhasználói élményt nyújtson, mint egy telepített, vastag kliens alkalmazás. Technológiai szinten az újdonságot a Service Worker jelenti, ami biztosítja az offline működés feltételeit. Ezt a komponenst az Angular csapat becsomagolta egy @angular/service-worker package-be, ami lehetővé teszi, hogy nagyon kényelmesen készítsünk Angularral PWA-t. A CLI 1.6 bétájában már megjelenik a –service-worker kapcsoló, későbbi verziókban pedig várható, hogy ez lesz az alapértelmezett, tehát érdemes készülni rá.

A PWA nem egy fekete-fehér terület, vannak hátrányai (például verzió frissítés), ami miatt egyáltalán nem biztos, hogy minden esetben megéri használni. Érdemes viszont megismerkedni vele és szem előtt tartani mint lehetőséget (és mint biztonsági tényezőt is), mert jelentősen növelhetjük vele a felhasználói élményt.

Angular Universal

A 4.0 verziótól már az Angular részeként elérhető Angular Universal célja, hogy platform és eszköz támogatást adjon szerver oldali HTML renderelés megvalósításához. A feladat nem csak annyi, hogy a backendről érkező HTML sztringet beszúrunk a weboldal közepére, hanem támogatni kell a kereső motorokat és az oldalról tartalmat kiollózó egyéb alkalmazásokat (pl. Facebook, Slack), miközben többféle stratégiát (pl. statikus renderelés fordításkor) is kell tudnia támogatni.

Olyan környezetben, ahol a teljesítmény problémákat okoz, érdemes megismerkedni a fogalommal és az Angularos megvalósítással.

Angular Elements

A szoftverfejlesztés egyik problémája, hogy általában le kell tenni a voksunkat valamelyik keretrendszer mellett, és utána annak a szabályai szerint kell játszanunk. Különösen bosszantó ez egy olyan környezetben, mint a web, ahol mindegy, hogy milyen kliens oldali platformot választunk, végül mezei HTML és JavaScript kód fog futni a böngészőben, miközben az egyes keretrendszerek között nincs, vagy csak nagyon körülményes az átjárás.

Ezen a problémán próbál segíteni az egyelőre csak az Angular Labs részeként elérhető Angular Elements, aminek az a célja, hogy a Custom Elements szabvány lehetőségeit felhasználva úgy csomagolja be az Angularos komponenseinket, hogy más keretrendszerek számára standard HTML elementnek tűnjenek. A kezdeményezés még nagyon gyerekcipőben jár, jövőre lehet belőle valami, mindenesetre üdítő látvány, hogy az Angular csapat nem zárkózik be, nyitott más platformok felé, és támogatni akarja a library fejlesztőket.

Ezek voltak a visszatérő témák, de ezeken kívül még sok más terület is terítékre került: forms, animations, DevKit, Schematics, ABC, Query, DI, aria, internationalization, flex layout, security, burnout, VR – szerencsére a videók mind megtekinthetők a Youtube-on. Mindkét nap keynote-tal kezdődött, érdemes megnézni őket.

Ráadásként az Angular csapat egy ígéretet is tett: kigyomlálják a Github repóban található közel 2000 issue-t és több, mint 300 PR-t. Külön embert vettek fel erre 🙂

Technorati-címkék: Angular,web,JavaScript,TypeScript

Több website-ot tartalmazó solution publikálása Azure-ra

Feltöltött fájl típusának meghatározása

2 Replies

Nem ritka feladat, hogy egy weboldalon szeretnénk megszűrni, hogy a felhasználók milyen típusú fájlokat tölthetnek fel. Fontos, hogy a felhasználó fényképe valóban egy böngészőben megjeleníthető képfájl legyen, vagy hogy a feltöltött XLSX fájl valóban Excel fájl legyen, hiszen különben nem tudjuk belőle kiolvasni az adatokat.

Erre a problémára a klasszikus megoldás a feltöltött állomány kiterjesztésének vizsgálata. Azonban egy percre se felejtsük el, hogy a vizsgált fájlnevet és vele együtt a kiterjesztést is a HTTP kérés részeként kapja meg a weboldal, azaz pontosan annyira bízhatunk meg benne, mint a HTTP kérés bármelyik más részében. Semennyire.

Egy kicsivel jobb megoldás, ha beleolvasunk a fájlba, és megkeressük azokat a bájtokat, amik egy adott fájltípusra jellemzőek. Ezeket a bájtokat hívják “file (type) signature”-nek. Gary Kessler weboldalán elég sok ilyen signature-t összegyűjtött, sőt ott további weboldalakra, adatbázisokra, eszközökre is találhatók hivatkozások.

Számunkra most az a nagy kérdés, hogy .NET kódból hogyan valósítjuk meg ezt a legegyszerűbben. Nyilván tökéletesen működő megoldás, ha beletekerünk a fájlba a megadott offsetig, onnan kiolvassuk a szükséges számú bájtot, majd összehasonlítjuk őket a várt bájtokkal. Ez jól fog működni addig, amíg valamelyik gyártó nem változtat egy kicsit a fájl formátumon, akkor ugyanis frissítetünk kell a kódunkat.

Egy kicsit “hivatalosabb” megoldás, ha a FindMimeFromData Win32 API függvényt használjuk, amit egyébként az Internet Explorer használ MIME type sniffingre. Némi P/Invoke trükközéssel meg is hívhatjuk .NET-ből, ahogy az alábbi példa is mutatja:

using System;
using System.Runtime.InteropServices;

/// <summary>
/// Helper class to detect the MIME type based on the file header signature.
/// </summary>
public static class MimeSniffer
{
    /// <summary>
    /// Internet Explorer 9. Returns image/png and image/jpeg instead of 
    /// image/x-png and image/pjpeg.
    /// </summary>
    private const uint FMFD_RETURNUPDATEDIMGMIMES = 0x20;

    /// <summary>
    /// The zero (0) value for Reserved parameters.
    /// </summary>
    private const uint RESERVED = 0;

    /// <summary>
    /// The value that is returned when the MIME type cannot be recognized.
    /// </summary>
    private const string UNKNOWN = "unknown/unknown";

    /// <summary>
    /// The return value which indicates that the operation completed successfully.
    /// </summary>
    private const uint S_OK = 0;


    /// <summary>
    /// Determines the MIME type from the data provided.
    /// </summary>
    /// <param name="pBC">A pointer to the IBindCtx interface. Can be set to NULL.</param>
    /// <param name="pwzUrl">A pointer to a string value that contains the URL of the data. Can be set to NULL if <paramref name="pBuffer"/> contains the data to be sniffed.</param>
    /// <param name="pBuffer">A pointer to the buffer that contains the data to be sniffed. Can be set to NULL if <paramref name="pwzUrl"/> contains a valid URL.</param>
    /// <param name="cbSize">An unsigned long integer value that contains the size of the buffer.</param>
    /// <param name="pwzMimeProposed">A pointer to a string value that contains the proposed MIME type. This value is authoritative if type cannot be determined from the data. If the proposed type contains a semi-colon (;) it is removed. This parameter can be set to NULL.</param>
    /// <param name="dwMimeFlags">The flags which modifies the behavior of the function.</param>
    /// <param name="ppwzMimeOut">The address of a string value that receives the suggested MIME type.</param>
    /// <param name="dwReserverd">Reserved. Must be set to 0.</param>
    /// <returns>S_OK, E_FAIL, E_INVALIDARG or E_OUTOFMEMORY.</returns>
    /// <remarks>
    /// Read more: http://msdn.microsoft.com/en-us/library/ms775107(v=vs.85).aspx
    /// </remarks>
    [DllImport( @"urlmon.dll", CharSet = CharSet.Auto )]
    private extern static uint FindMimeFromData(
            uint pBC,
            [MarshalAs( UnmanagedType.LPStr )] string pwzUrl,
            [MarshalAs( UnmanagedType.LPArray )] byte[] pBuffer,
            uint cbSize,
            [MarshalAs( UnmanagedType.LPStr )] string pwzMimeProposed,
            uint dwMimeFlags,
            out uint ppwzMimeOut,
            uint dwReserverd
    );


    /// <summary>
    /// Returns the MIME type for the specified file header.
    /// </summary>
    /// <param name="header">The header to examine.</param>
    /// <returns>The MIME type or "unknown/unknown" if the type cannot be recognized.</returns>
    /// <remarks>
    /// NOTE: This method recognizes only 26 types used by IE.
    /// http://msdn.microsoft.com/en-us/library/ms775147(VS.85).aspx#Known_MimeTypes
    /// </remarks>
    public static string GetMime( byte[] header )
    {
        try
        {
            uint mimetype;
            uint result = FindMimeFromData( 0, 
                                            null, 
                                            header, 
                                            (uint) header.Length, 
                                            null, 
                                            FMFD_RETURNUPDATEDIMGMIMES, 
                                            out mimetype, 
                                            RESERVED );
            if( result != S_OK )
            {
                return UNKNOWN;
            }

            IntPtr mimeTypePtr = new IntPtr( mimetype );
            string mime = Marshal.PtrToStringUni( mimeTypePtr );
            Marshal.FreeCoTaskMem( mimeTypePtr );
            return mime;
        }
        catch
        {
            return UNKNOWN;
        }
    }

}

Ez a függvény megbízhatóan működik, azonban csak a 26 leggyakoribb fájltípust képes felismerni. Ami egyébként nem kevés, a fájó pont inkább az, hogy az Office formátumokat ZIP-ként ismeri fel.

Némi keresgéléssel ráakadhatunk a neten más projektekre is, például a CodePlexen található FileTypeDetective kevesebb fájl típust ismer, de pontosabban azonosítja az Office állományokat. Ráadásul a lényeget megtaláljuk a forráskódjában.

Akármelyik módszert választjuk is, ne felejtsük el, hogy bevezettünk egy külső függést a rendszerbe, ráadásul azt sem tudhatjuk, hogy mennyire időtálló a megoldásunk.

Technorati-címkék: file signature,security,file upload

Mockupkészítő eszközök

7 Replies

Kevés olyan hasznos dolog van a fejlesztő életében, mint a mockupkészítő eszközök. Ezek olyan szoftverek, amelyek segítségével leskiccelhetjük, hogyan fog kinézni az alkalmazásunk. Bár a mockupok tipikusan fapadosan kinéző drótváz ábrák, mégis számtalan előnyük van:

Legalább egyszer mi is végiggondoljuk, hogy milyen funkciókat szeretnénk, és azok hogyan fognak megjelenni a felhasználói felületen. Akár a teljes alkalmazást lerajzolhatjuk, és a hagyományos képfájlokkal ellentétben a mockupkészítő eszközök által biztosított interakcióknak köszönhetően akár ki is próbálhatjuk.
Az ábra felett eszmét cserélhetünk másokkal, akár a megrendelővel, akár más tervező/fejlesztő kollégákkal. Amikor mindkét fél látja, amiről beszélnek, sokkal fókuszáltabb és hatékonyabb tud lenni a megbeszélés. Ha valakinek ötlete van, azt sokkal gyorsabban át lehet vezetni egy statikus ábrán, mint egy élő kódon.
Az ábra mellé villámgyorsan feljegyezhetjük a legjobb ötleteinket (pl. “A Mentés működjön Ctrl+S-re is.”), ami sokkal gyorsabb, mint dokumentációt írni, arról nem is beszélve, hogy egy rövid feljegyzést sokkal valószínűbb, hogy elolvas az implementációt végző fejlesztő.
A mockup alapján szinte mindenki, a grafikus, a sitebuilder, a fejlesztő azonnal el tud kezdeni dolgozni és még a megrendelő is látja, hogy halad a projekt.
Egyes eszközök kódvázat is tudnak generálni az ábrából, ami talán még használható kiindulópont is lehet a fejlesztés során.

Összességében azt tapasztaltuk, hogy a mockupok egyértelműbbé teszik mindenki életét, és bár látszólag plusz munkát igényelnek, a félreértések megszűntetésével végül spórolhatunk velük.

Szerintem teljesen mindegy, hogy milyen eszközzel készülnek a mockupok, a lényeg, hogy a rajzolás ne igényeljen több időt, mint majd az implementáció. Ennek fényében én sokáig papíron mockupoltam, de ma már vannak egészen hatékony eszközök.

Balsamiq Mockups

A Balsamiq egy Adobe Air-re épülő, kifejezetten statikus mockup készítésére tervezett alkalmazás. A használata pofonegyszerű, talán ennek köszönhetően vált a legelterjedtebb eszközzé ezen a piacon. A Balsamiq nem ingyenes, de 79 dollárt simán megér, mi is ezt használjuk már évek óta.

Ami tetszik benne:

Bármilyen alkalmazást megtervezhetünk benne, legyen az desktop, webes vagy mobil app:

A Balsamiq már annyira elterjedt, hogy kis keresgéléssel kész template-eket találhatunk a neten, például akár Windows Phone vagy Windows 8 fejlesztéshez.
Ahogy a fenti ábrán is látszik, a beépített vezérlők kifejezetten rondák (bár az újabb Balsamiq verzióban már “szép” skint is lehet rájuk húzni), ami azért nagyon praktikus, mert egy megbeszélés során a dizájn nem vonja el a figyelmet a lényegről, ami mockupok esetén a funkció, a layout és a navigáció. Aki találkozott már olyan ügyféllel, aki 2-3 órát képes volt elfilózni azon, hogy egy-egy ikon mennyire felismerhető, az tudja, hogy miért preferálom a ronda mockupot.
Az ábrák képesek minimális interakcióra, ugyanis valamennyi vezérlő kattintható és a kattintás hatására képes elnavigálni minket egy másik oldalra. Egy popup ablakot ennek megfelelően úgy rajzolunk, hogy duplikáljuk a teljes ábrát, majd a másolatra rárajzoljuk a felugró ablakot. Ez ugyan plusz munka, de szinte mindent kipróbálhatóvá tesz.
A vezérlők újrafelhasználható egységekbe csomagolhatók, így például egy menüt, vagy egy master page-et elég egyszer megrajzolnunk és egy helyen karbantartanunk.
A Balsamiq-nak van teljes képernyős vetítő üzemmódja, ami egyeztetéseken nagyon praktikus szokott lenni.
Az ábrákat képes PDF dokumentumba exportálni, ráadásul úgy, hogy kattinthatóak maradnak, tehát egy sima PDF olvasóval kipróbálhatóvá válik a mockup.

Néhány tanács azoknak, akik most kezdenek a Balsamiq megismeréséhez:

Vásárlás előtt próbáld ki a szoftvert, van belőle trial és böngészőben futtatható próba változat is.
Nézd végig a vezérlőket, hiszen nincs bosszantóbb annál, mint amikor az ember megrajzol egy összetettebb UI elemet, azután pedig kiderül, hogy készen is behúzhatta volna az eszköztárról.
Mielőtt nagyobb rajzolásba fogsz, keress a neten kész template-eket, például a MockupsToGo oldalán jó adag található.
A Balsamiq használata egyszerű, hamar rá lehet érezni, mégis azt javaslom, hogy fusd végig a dokumentációt, megéri. Sőt, ha van 2 órád, végigolvasni is megéri. Az újrafelhasználható komponensek (azaz Symbols) használata talán nem teljesen magától értetődő, de arról is van doksi.
A gyorsbillentyűk használata sokat dobhat a tempón.
A fájlnevekhez már az elején találj ki egy elnevezési konvenciót. Ez azért fontos, hogy az oldalak közötti linkelés tisztán fájlnév alapján megy (nincs projekt fájl), és ha átnevezel egy fájlt a diszken, nem fognak működni a rá mutató linkek.

Honlap: http://balsamiq.com

Infragistics Indigo Studio

Az Indigo Studio egy pár hete megjelent új eszköz, ami a Balsamiq monopóliumát igyekszik megdönteni az alábbiakkal:

Szebb, élethűbb mockupok készíthetők vele (bár szerintem ez nem előny).
Képes összetettebb interakciókra és animációkra.
Tud Balsamiq fájlt importálni (ez mekkora ötlet ;-).
A V1 verzió ingyenes és az is marad, majd csak annak kell fizetni, aki a V2 verziót akarja használni. Ez egy érdekes megoldás arra, hogy egy új termék betörjön a piacra (még érdekesebb lenne, ha a letöltés egyszerűbb lenne).

Az első ismerkedéshez készítettek egy 6 részes videó sorozatot, szerintem azzal érdemes kezdeni.

Mivel futó projektjeinkben nem akarunk váltani, ezért még nem ástam bele magam az Indigo Studio használatába, de majd a következő projekt előtt megnézem. Van már vele valakinek gyakorlati tapasztalata?

Visual Studio 2012

A VS 2012 egyik rejtett szépsége, hogy beépít a PowerPointba egy Storyboarding nevű fület, amely olyan elemeket tartalmaz, amiket akár mockup rajzolásra is használhatunk. Azért “akár”, mert ahogy a neve is mutatja, itt nem kifejezetten a UI a fontos, hanem a felhasználáshoz kapcsolódó sztori.

A panel alján található Find more Storyboard Shapes online link a Visual Studio Gallery Storyboard Shapes kategóriájába visz, ahonnan további rajzelemeket tölthetünk le. Ez a kategória egyelőre nem tartalmaz sok elemet, de azért vannak már használhatók, természetesen némelyik fizetős. Itt van például a Windows8Templates:

A PowerPoint óriási előnye, hogy alig kell tanulni a használatát, ráadásul minden gépen elérhető. Ha bővülne a közösségi kínálat, gyorsan nagyon használhatóvá válna.

Pár bevezető link:

Ti szoktatok mockupolni, és ha igen, milyen eszközt használtok mockup elkészítésére?

Technorati-címkék: mockup,wireframe,storyboard,Visual Studio,PowerPoint,Balsamiq