Beiträge

Veröffentlicht am

Ad-hoc ist nicht gleich Roaming(-Preis)

Ich nutze nun seit gut 6 Monaten den Mobilize Charge Pass und bin damit wirklich zufrieden. Im Allgemeinen ist das Produkt für den Preis sehr gut – mit 4,99 EUR im Monat erhält man Zugang zu Ionity Säulen mit 0,39 €/kWh.

Um sich das lästige Scannen des QR-Codes und das Eingeben von Kartendaten zu ersparen, habe ich gerne auch Mal die Mobilize Ladekarte an AC-Ladesäulen fremder Anbieter vorgehalten.

Als Neuling der E-Mobilität meinte ich, dass er Ad-Hoc Preis einer Ladesäule der gleiche ist, unabhängig davon ob man die Mobilize Ladekarte vorhält oder den QR-Code scannt. Schließlich ist ja beides ein Laden ohne vorherigen Ladevertrag, also ad hoc). Leider ist das Falsch gedacht.

Mir ist leider aufgefallen, dass im Roaming andere Gebühren und Preise berechnet werden, als wenn man den QR-Code direkt scannen würde. Die Anbieter unterscheiden tatsächlich zwischen Roaming (anderer Anbieter) und Ad-hoc-Preis (QR-Code).

Mein Tipp ist deswegen, auch wenn es umständlicher ist, immer den QR-Code zu scannen!

Beispiele

Betreiber Konditionen
QR-Code		 Abrechnung
Mobilize
Ladesäule SWM (AC)
  • 0,49 €/kWh,
  • keine Blockiergebühr
  • 0,51 €/kWh
  • Ab der 2. Stunde 0,12 €/Min Blockiergebühr
„be.energised“ (AC)
  • 0,52 €/kWh
  • Blockiergebühr erst ab der 4. Stunde
  • 0,51 €/kWh
  • Ab der 2. Stunde 0,12 €/Min Blockiergebühr

Es war wirklich ein Krampf die Preisangaben für das Roaming auf den Webseiten von Mobilize zu finden. Auf GoingElectric fand ich zum Glück dann die Auflistung der Konditionen: https://www.goingelectric.de/stromtankstellen/anbieter/angebot/Mobilize-Charge-Pass-INTENSE-Renault-Deutschland-AG/688/.

P.S.: Auch wenn man es selten brauchen wird, aber die 0,51 €/kWh werden auch dann herangezogen, wenn der Ad-hoc-Preis höher ist – der Ladesäulenanbieter beim Zahlen mit QR-Code also mehr verlangt (siehe das 2. Beispiel).

Veröffentlicht am

Warum ist der neuen Personalausweis für die deutsche Verwaltung so besonders?

Warum ist die Digitalisierung der deutschen Verwaltung ist untrennbar mit ELSTER und dem neuen Personalausweis verbunden?

Dies begründet sich mit folgenden zwei Gesetzen:

Dem EGoVG §2, dort steht:

(1) Jede Behörde ist verpflichtet, auch einen Zugang für die Übermittlung elektronischer Dokumente, auch soweit sie mit einer qualifizierten elektronischen Signatur versehen sind, zu eröffnen.
(2) Jede Behörde des Bundes ist verpflichtet, den elektronischen Zugang zusätzlich durch eine De-Mail-Adresse im Sinne des De-Mail-Gesetzes zu eröffnen, es sei denn, die Behörde des Bundes hat keinen Zugang zu dem zentral für die Bundesverwaltung angebotenen IT-Verfahren, über das De-Mail-Dienste für Bundesbehörden angeboten werden.
(3) Jede Behörde des Bundes ist verpflichtet, in Verwaltungsverfahren, in denen sie die Identität einer Person auf Grund einer Rechtsvorschrift festzustellen hat oder aus anderen Gründen eine Identifizierung für notwendig erachtet, einen elektronischen Identitätsnachweis nach § 18 des Personalausweisgesetzes, nach § 12 des eID-Karte-Gesetzes oder nach § 78 Absatz 5 des Aufenthaltsgesetzes anzubieten.

 

Das bedeutet zusammengefasst, dass ein Antrag an eine Bundesverwaltung versendet werden kann, wenn der Antrag entweder mit einer qualifizierten elektronischen Signatur signiert wurde, oder aber die Identität durch eine eID-Karte gesichert wurde, oder eine De-Mail-Adresse verwendet wurde – sofern das Fachverfahren des Bundes auch De-Mail nutzen kann.

Wie man hier aber auch feststellen kann, ist in dieser Auflistung weder von eID-Karten anderer Länder, noch von ELSTER die Rede.

Dazu finden sich jedoch in der BayBITV §4 weitere Angaben:

(1) 1Die Schriftform kann auch ersetzt werden, wenn
1. der Beteiligte anhand der dazu erforderlichen Daten sicher identifiziert ist, indem
a) seine Identität
aa) mit dem Melderegister oder einer anderen verlässlichen Quelle im Sinne der Nr. 1 Nr. 1 des Anhangs der Durchführungsverordnung (EU) 2015/1502 abgeglichen oder
bb) durch persönliches Erscheinen und Vorlage eines amtlichen Lichtbildausweises bei einer Behörde festgestellt
wurde und
b) ihm die für die Erzeugung des Authentifizierungsmittels erforderlichen Parameter anschließend auf dem Postweg übermittelt oder persönlich ausgehändigt wurden,
2. das verwendete Authentifizierungsverfahren vom Staatsministerium der Finanzen und für Heimat (Staatsministerium) zertifiziert und als solches bekannt gemacht ist,
3. die Erklärung unmittelbar in einem elektronischen Formular oder über eine elektronische Schnittstelle abgegeben wird, die von der Behörde zur Verfügung gestellt werden,
4. die Integrität und Vertraulichkeit des übermittelten Datensatzes durch technische Maßnahmen gewährleistet wird, die die gesetzlichen Anforderungen an die Sicherheit der verarbeiteten Daten erfüllen, und
5. die Barrierefreiheit nach § 1 Abs. 1 Satz 1 und 2 gewährleistet ist.

In Abs 1 1. a) aa) findet sich die Referenz zur Durchführungsverordnung, die besagt, dass ein euopräische eID akzeptiert werden muss, wenn Sie das selbe Vertrauensniveau erfüllt wie diejenigen, die bereits von der deutschen Verwaltung akzeptiert wird.

Abs 1 1 b) spielt auf ELSTER und auch authega an, sprich auf  Identifikationswege, die die Daten des Benutzers über einen Postweg (PIN-Brief) verifizieren.

Quellen:

https://www.gesetze-im-internet.de/egovg/__2.html
https://www.gesetze-bayern.de/Content/Document/BayBITV-4

Veröffentlicht am

Was ist eIDAS?

eIDAS steht für electronic IDentification, Authentication and trust Services und steht oft synonym für eIDAS-Verordnung (EU) Nr. 910/2014 und alle daraus resultierenden nationalen Gesetzgebungsverfahren und die zugehörigen EU- Durchführungsverordnungen.

eIDAS ist insofern eigentlich die digitale Analogie zu dem was in Europa schon länger gilt, nämlich dass Ausweismitteln anderer Mitgliedsstaaten in den EU Mitgliedsstaaten als Ausweise anerkannt werden.

Mit eIDAS soll nun selbiges auch für elektronische / digitale Identitäten und die dazu ausgegebenen Authentifizierungsmittel (eID-Karten) gelten.

Das bedeutet also, dass, beispielsweise, eine polnische eID-Karte  auch in Deutschland gegenüber Verwaltungsdienstleistungen als schriftformersetzendes Identifikationsmittel eingesetzt werden kann.

Möchte man eIDAS in einem Klassendiagramm darstellen, so wäre eIDAS ein Interface, das von den Klassen der jeweiligen Identifizierungsmittels/-dienstes genutzt wird.

eIDAS ist also ein Versprechen – das Verprechen gegenüber dem Bürger, dass das Authentifizierungsmittel auch in anderen Staaten eingesetzt werden kann. Das Versprechen gegenüber den Anbietern, dass ein gewisser Datensatz erwartbar ist.

Quellen:

Country overview (europa.eu)

Digital Homepage (europa.eu)

eID (europa.eu)

Veröffentlicht am

Verbesserungsvorschläge für die Präsentation von Software oder Anwendungsfällen

Ich selbst habe bereits einige Präsentationen von Software(-systemen) durchgeführt, und habe noch mehr Abnahmepräsentationen als Teilnehmer beigewohnt.

Dabei sind mir immer wieder Dinge aufgefallen, die ich für mich mitgenommen und verbessert habe, um eine effektivere und verständlichere Vorstellung zu ermöglichen. Diese Erkenntnisse wollte ich hier festhalten, damit auch andere davon profitieren können.

Dabei bleibt vor allem eines festzuhalten: Vorbereitung ist die halbe Miete. Man muss nicht unbedingt eine Generalprobe abhalten, aber man sollte sich durchaus zu folgenden Aspekten Gedanken machen.

  1. Persona verwenden und vorstellen

    Nichts ist langweiliger und weniger einprägsam als Max Mustermann, wohnhaft in der Musterstraße 123 in 12345 Musterhausen. Eine gute Präsentation lebt auch von einer sprechenden, glaubhaften Geschichte (Stichwort: Storytelling). Und eine gute Persona hilft dabei, den Anwendungsfall besser zu demonstrieren. Legen Sie sich eine Persona zurecht und verwenden Sie diese auch konsequent in der Präsentation. Gleich bei der Vorstellung kann man so auch implizit und elegant die zugrunde liegende User Story aufgreifen.

  2. Liste der Anwendungsfälle aufschreiben

    Dieser Punkt ist extrem wichtig, gerade wenn man mehrere User Stories oder Änderungen vorstellt. Oft ist es so, dass die Anforderungen an bestimmten Punkten Synergien aufweisen, weil zum Beispiel gleiche Oberflächen betroffen sind. Deshalb ist es umso wichtiger sich vorab zu vergegenwärtigen, in welchem Schritt der Präsentation man ggf. kurz abschweift um eine kleinere Anforderung mit vorzustellen.

    Beispiel: Der Checkout-Prozess wurde grundlegend überarbeitet, es gab aber auch Verbesserungen an der Warenkorbansicht, der Gutscheineingabe und an der Produktsuche. Es ist also nur logisch, zuerst sich ein Produkt zu suchen, und dabei wenn möglich gleich die Verbesserungen an der Suchfunktion anzusprechen und zu demonstrieren, um anschließend in der Warenkorbansicht die dort eingefügten Verbesserungen zu zeigen und erst dann den Checkout und die verbesserter Gutscheineingabe zu demonstrieren.

    Das mag für Sie trivial klingen, wird aber oftmals nicht gemacht. Stattdessen wird jede Anforderung der Liste nach abgearbeitet und dabei manche Oberfläche x Mal durchgeklickt, was sich für die Zuschauer und Zuhörer sehr ermüdend und repetitiv anfühlt.

  3. Funktionsweise testen

    Vor jeder Präsentation ist es wichtig, sich mit der Funktionsweise der Software auseinanderzusetzen! Das E-Maileingabefeld unterstützt keine Umlaute? – Gut dann auch wähle ich für meine Präsentation eine E-Mail ohne Umlaute.
    Es geht hier ausdrücklich nicht darum Fehler zu kaschieren, sondern sich mit der Funktionsweise der Software auseinanderzusetzen. Wie oft kommt es vor, dass bei der Präsentation der Präsentator, beispielsweise an den Passwortkomplexitätsrichtlinien, scheitert, weil er 123456 in der Schnelle eingeben wollte? Oder weil er eine URL beim Kunden aufrufen wollte, die aber für Aufrufe aus dem Internet nicht freigeschalten war?
    Es gibt viele mögliche Gründe, weswegen das System sich nicht so verhält, wie Sie es angenommen haben. Deswegen gilt im Rahmen einer guten Vorbereitung – testen Sie was Sie präsentieren wollen und ersparen Sie sich und anderen die hektische Lösungssuche während der Präsentation. P.S.: Sprechen Sie auch deswegen auch immer noch mal mit den Technikern!

  4. Relationen zwischen Akteuren skizzieren

    Auch dieser Punkt ist wichtiger, als man denkt. Skizzieren Sie sich, welche Interaktionen ggf. entstehen. Beispielsweise zwischen dem Supportmitarbeiter und dem Nutzer und wie sie dies in der Präsentation zeigen möchten. Im Idealfall präsentieren Sie einen Anwendungsfall, bei dem der Nutzer in einen Fehler läuft und leiten dann geschickt über zur Rolle des Supportmitarbeiters, der dem Kunden hilft, sein Konto freizuschalten. Wichtig ist es diese Rollenwechsel auch in der Präsentation deutlich zu kommunizieren.
    Denken Sie auch immer daran, dass nicht alle Rollenwechsel so offensichtlich sind wie zwischen Kunde und Support-Agenten – so ist es beispielsweise schon schwerer zwischen Mitarbeiter und Supervisor zu differenzieren, wenn auch beide in derselben Oberfläche arbeiten. Im besten Fall kommen schnell verwirrte Rückfragen „Wie kommt der Kunde denn zu unseren Eingabemasken für den Support?“, im schlimmsten Fall verlassen die Leute Ihre Präsentation mit einem falschen Eindruck, wie das System aufgebaut oder verwendbar ist.

  5. Präsentationsskript ausarbeiten

    Auch wenn es banal klingt, aber alles, was man sich aufschreibt, muss man nicht im Kopf behalten. Und das ist in einer Stresssituation genau das Richtige. Das Skript muss im Übrigen nicht wortgenau vorgeben, was man sagt, aber es empfiehlt sich genau das festzuhalten, was wir in den vorhergehenden Stichpunkten schon festgehalten haben, also zum Beispiel:

    „auf Oberfläche Warenkorb, Spreche an Verbesserung TICKET-ID: 1234 >Übersichtlichere Berechnung des Gesamtbetrags<;“

    oder

    „… Nach Abschluss Kontoregistrierung – WECHSEL ZU SUPPORT-GUI – Ansprechen, ich bin jetzt Supportmitarbeiter. Telefoniere gerade mit dem Kunden und bediene Funktion „Konto entsperren“ …“

Während der Präsentation

  • Bei Online-Meetings und Telefonkonferenzen darauf hinweisen die Mikrofone stummzuschalten, oder noch besser, selbst stummschalten.
  • Einen Timer / eine Uhr sichtbar stehen haben und darauf achten nicht zu überziehen. Nach 30 Minuten sollte man fertig sein.
  • Fragen am besten nach hinten stellen.
  • Am Ende der Präsentation auch noch wichtige URLs nennen, wenn diese für Teilnehmern verfügbar sind.

Nach der Präsentation

  • Eine Zusammenfassung der vorgestellten Anforderung schicken (eventuell mit Ticket-Links). Die wenigsten der Teilnehmer werden mitschreiben und gerade diesen Teilnehmern hilft die nachträgliche Zusammenfassung, auch um selbst noch mal etwas genauer nachzuforschen.
  • Klärungen zu aufgekommenen Fragen, die nicht sofort beantwortet werden konnten, nachreichen. Nicht jede Frage lässt sich einfach in einem Termin beantworten. Deswegen sollten sie aber trotzdem beantwortet werden. Damit sich keiner vergessen oder vernachlässigt fühlt, empfiehlt es sich, Antworten zu komplexeren Fragen nach dem Termin schriftlich zu beantworten.
  • URLs zu gezeigten Systemoberflächen und Testwerkzeugen bereitstellen. Damit auch interessierte Teilnehmer sich mit dem System oder der Software beschäftigen können. Sicher, viele werden sich nicht damit abgeben, aber gerade für den einen oder anderen mag es doch hilfreich sein. Und wenn es nur der Azubi oder Praktikant ist, der es sich noch mal ansieht. Je mehr Augen sich damit beschäftigen, desto besser.

Ich hoffe, ich konnte Ihnen einige nützliche Ansatzpunkte geben, die auch Ihnen helfen, bei der nächsten Abnahmepräsentation Ihre Zuhörer besser mitzunehmen und allgemein das Verständnis für die Anforderungen zu erhöhen.

Veröffentlicht am

Axure – Using Notes to support your prototyping workflow

Document your intentions and ideas

The notes section in Axure is another underrated feature of Axure. Especially when designing a prototype as a team. In this scenario, I think the following rule of thumb should apply.

Write at least two notes for every page, describing:

  • Page intention / Desired User Behavior
  • Reasons Why / Triggers
  • Obstacles
  • Improvements (to keep track of good ideas)

Additionally, you can add the following notes, they really make sense, I see them as CAN-fields or Nice-to-have fields. Those would be:

  • Targeted Version
  • Mobile Behaviour (what changes on smaller screens)

The comment feature should be used with fellow colleagues, who have access to your team project and therefore have gone through some kind of expertise check – otherwise they hopefully wouldn’t have access to your project. If you want to catch feedback from a broader audience of spectators or a not so expert crowd, you should use the discussion-feature that comes with the HTML-Export.

But the best tool doesn’t do you any good if you are not used to using it. So practice or even force yourself to fill in at least two notes. Your future self will thank you and you will always keep track of the essential information that is behind each screen design.

Tipp: If you are uncomfortable with others being able to read your notes –  you can exclude the notes from getting exported into HTML by simply creating or customizing the HTML-Export in Axure.

Also you can add notes to each element. I don’t recommend you do this, because it is very tedious work and I don’t think it offers that much of a benefit. But in case you are wondering, here is a idea on how to use notes on an element level. You can use notes organized into named sets to document your notes right.

  • Set: Planning
    • Improvements
    • Alternatives
  • Set: Workflow
    • Note
    • Last edit
  • Set: CMS
    • CMS Location
    • CMS Key

P.S.: This is an article that I originally posted in German and recently translated to English for a broader audience. See the original post if you want to read it in German.

Veröffentlicht am

Axure Prototyping – Verwendung von Notizen

Dokumentieren von Intentionen und Ideen.

Axure bietet von Haus aus die Möglichkeit Notizen zu einer Seite zu hinterlegen und zusätzliche Notizfelder anzulegen. Axure Notizen werden oft vergessen, da sie für die funktion des Klickdummies unwichtig sind und in der Programmoberfläche auch nicht sofort angezeigt werden. Jedoch entfalten sie wenn sie richtig und konsequent gepflegt werden ihre volle Wirkung und sind im Gegenteil zu manch anderem Feature von Axure auch in Projekten sinnvoll, in denen nur ein Einzelner an einem Projekt arbeitet – wer erinnert sich schließlich nach 3 Monaten noch was er sich bei der Gestaltung einer Seite im Detail gedacht hat?

Projektnotizen sind also eine Form der „Vor-Ort“ (In-Place) Dokumentation, ähnlich wie Kommentare im Quellcode für einen Entwickler.

Damit man die Notizfunktion optimal nutzen kann, bietet es sich an mit fogenden Feldern zu arbeiten:

  • Seitenintention / erwünschtes Nutzerverhalten
  • Konversionsgründe / -anreize
  • Konversionshemnisse/-hindernisse
  • Verbesserungspotenzial

Zusätzlich nutze ich noch gerne folgende Felder – welche ich jedoch nicht als zwingend erforderlich sehe:

  • Zielversion / Umsetzung in
  • Mobiles Verhalten

Wie aus dem Screenshot zu ersehen ist, leiten die Notizfelder den Fokus auf die richtigen Fragen, die man sich bei der Seitengestaltung fragen stellen sollte, und greift somit Kerngedanken der Usability (was soll passieren, wie soll es passieren, was kann schiefgehen) auf und führt sie den Planer in Form von Eingabefeldern wieder vor Augen. Somit bleibt der Fokus immer auf den essenziellen Informationen hinter dem jeweiligen Oberflächendesign.

Ziel der Notizfelder ist es also zum einen dazu geeignet die Metainformationen und Kriterien, welche zur Erstellung einer Seite beigetragen haben zu bündeln und abzufragen, als auch die Informationsfülle zu unterteilen. Die Unterteilung in einzelne themenbezogenen Notizen, hilft zudem die Schreibbarriere zu brechen und klarer zu vermitteln, was gefordert ist. Ein einzelnes Notizfeld schreckt entweder ab, oder lädt dazu ein alles mögliche dort „abzuladen“.

Notizen an den Elementen – wofür?

Zusätzlich zu Seitennotizen bietet Axure die Möglichkeit direkt an Elementen Notizfelder zu verwenden. Dies ist besonders sinnvoll, um elementspezifische Eigenschaften festzuhalten. Beispiele hierfür wären:

  • CMS-Angaben
  • Angaben zu alternativen Designs (bspw.: Kachel ohne Icon)
  • Informationen zu möglichen Verbesserungen (Bsp.: Button Primärfarbe, bekommt Mouse-Over-Effekt in invertierter Farbgebung)

Um die Übersicht am Element zu gewährleisten und beim Export besser steuern zu können, welche Informationen verwendet werden, können die Notizen noch gruppiert werden in sogenannten „Sets“.

Ich benutze dabei gerne ein Set namens Planung, welches aus den Feldern Alternativen und Verbesserungen besteht.

Tipp:

Notizen können während des Exportvorgangs von Axure (HTML, Word) auch ausgeschlossen werden. Somit werden kritische Informationen ausgeblendet und bleiben zum Beispiel bei einer Kundenpräsentation oder bei Bereitstellung von Wireframes auf einem internen Webserver, dem fachfremden Betrachter, verborgen.

Veröffentlicht am

Axure Widget Library – Checkliste für neue Widgets

Im nachfolgenden wird der Begriff Widget und Komponente synonym verwendet.

Die folgende Checkliste dient zur Qualitätssicherung von zentralen Widgets in einer Axure Widget Library. Insbesondere wenn diese Library von mehreren Personen gepflegt wird, entstehen oft unterschiedliche Ausbaustände in der Endversion. Meist erfüllen alle Widgets ihren Zweck und Verhalten sich wie gewünscht, jedoch gibt es einige Kniffe, die wenn beachtet den Kollegen einige Zeit und Frust bei der Verwendung der Widgets ersparen.

Mit diesem Hintergrund ist folgende Checkliste entstanden.

Folgende Punkte sollten erfüllt sein, bevor eine Komponente in einer Axure Widget Library freigegeben ist.

  • Eine Komponente hat einen eindeutigen und sprechenden Namen
  • Eine Komponente ist einer beschreibenden Gruppe zugeordnet (Beispiele: Basiselemente, funktionale Elemente, zusammengesetzte Komponenten)
  • Alle Elemente der Komponente sind zusammen gruppiert, die Gruppe ist gleichnamig zum Widget. Diese Maßnahme erleichtert es im späteren Projekt das Widget/die Komponente wiederzufinden bzw. zu suchen. Gleichzeitig bleiben die zusammengehörigen Elemente gruppiert und es entsteht kein „Salat“ aus Bausteinen, welche auf der Projekt-Prototypenseite zusammengewürfelt sind. Besteht das Widget aus einem dynamischen Panel, so ist das dynamische Panel trotzdem zu gruppieren.
Beispiel für eine Gruppierung
Axure Elemente sind gruppiert und die Gruppierung ist gleichnamig zur Komponente.
  • Die Komponente ist in sich funktional –  bei einer Auswahlliste (Dropdown) klappt zum Beispiel die Liste aus wenn auf das Icon für „Erweitern“ gedrückt wird und verschwindet wieder wenn das Icon für „Zusammenklappen“ gedrückt wird.
  • Alle Elemente des Widgets sind sauber benannt.
  • Das Widget verwendet nach Möglichkeit nur die eigenen Styles (bspw.: „IF_Icon Farbe Füllung„) oder eigens für das Widget definierte Styles (bspw.: „Dropdown Iconfarbe„). Dies ermöglicht es später in Projekten Farbänderungen einfacher umzusetzen und genau abzugrenzen.
  • Das Widget hat alle adaptiven Ansichten definiert, sofern dieses Feature verwendet wird. Widgets, die in einer bestimmten Ansicht keinen Sinn machen, werden aus der entsprechenden Ansicht gelöscht. Das Fehlen der mobilen Variante wird in der Seitennotiz „Mobiles Verhalten“ begründet und vermerkt, ebenso wie andere Verhaltensänderungen.
Die mobile Ansicht ist durch eine Notiz erklärt.
  • Das Widget verwendet keine globalen Variablen.
  • Es ist ein Icon hinterlegt für beide Icon-Felder (28 x 28 px & 56 x 56 px)
  • Die Check In-Notiz enthält eine explizite Auflistung aller erstellten Komponenten (eigene Sektion innerhalb der Nachricht).
Erstellt:

#Drowdown 1/1



#Dropdown 1/3

im Rahmen von TICKET-123.


----
Verändert:
..
....
----
Gelöscht:
....

Eine ähnliche Form dieser Checkliste verwenden wir um im Rahmen des Prototypings von Oberflächen, um zu gewährleisten, dass alle Widgets grundlegende Standards einhalten, was das Arbeiten deutlich vereinfacht. Da die Komponenten einer zentralen Komponentenbibliothek jedoch in vielen Projekten zum Einsatz kommen, ist es wichtig diese Standards zu forcieren, um das Arbeiten mit diesen Widgets erheblich zu vereinfachen und nacharbeiten zu verringern.
Jeder Planer kann sich somit sicher sein, dass wenn er beispielsweise die zum Widget hinterlegten Styles bearbeitet, er auch wirklich nur für diese Widgets Farb-/Stilanpassungen vornimmt. Würde das Widget beispielsweise Axure Default-Styles (Box1, Linie, …) verwenden, so könnte eine Farbänderung in allen möglichen Komponenten seines Projektes „durchschlagen“, was unnötige Nacharbeiten nach sich ziehen könnte.

Durch die Bereitstellung und Abarbeitung dieser Checkliste wird geholfen, diesen Mindeststandard zu dokumentieren und nachzuhalten.

Veröffentlicht am

Digital second amendment – Icon idea

So recently I came across an interessting comment making the point, that in order to save individuals rights in an interconnected society and with a more and more digital state there has to be something like a „digital second amendment“ (source: Splinternews – The fight for data encryption is the second amendment battle for the digital age). Meaning that the people should have unrestricted access to encryption software to protect their private data.

As I was thinking about what I had read, I came up with a logo.

Tilted stilized memory chip labeled +2A
Logo digital second amendment

Note: Design, Symbolism and Iconography is just a hobby of mine. I get my ideas from current events but this is not intended to be a political statement of any kind.

Veröffentlicht am

Interviewfragen für Prototypeninterviews

In letzter Zeit habe ich für ein Projekt für das IDIS mehrere Usability-Tests mit unterschiedlichsten Probanden durchgeführt. Ziel der Tests war es das Verhalten auf der Webseite und deren Bedienbarkeit zu erforschen. Dabei haben wir neben Daten zur Funktion auch Informationen zur Person, zur Motivation, zu Emotionen und Relevanz der Webseite erhoben.

Gute oder bewährte Fragen habe ich für meine Teammitglieder und für spätere Tests in einem Dokument festgehalten.

Diese Fragen finden Sie hier: Sammlung von Interviewfragen.