Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'ux'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Atlassian

Categories

  • Personal
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Invision Community
    • E-Commerce

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Invision Community
  • E-Commerce
  • Affixes & Prefixes

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Security
  • E-Commerce
  • Others

Categories

  • Thoughts
  • Debate
  • Health
  • Hobbies

Categories

  • Personligt
    • Åsikter
    • Humor
    • Spel
    • Träning
  • Allmänt
    • Internet
    • Program & tjänster
  • Intressant
    • Prylar
  • Professionellt
    • Management
    • Krav
    • Designs
    • Webbutveckling
    • Test
    • Atlassian
    • säkerhet
    • Förvaltning
    • Ehandel
    • Wordpress
  • Personligt_

Categories

  • Prologue
    • About This Book
  • The Tools
    • Jira Software
    • Confluence
    • Jira Service Management
  • The Inception Phase
    • Portfolio Management
    • Project Management
  • The Design Phase
    • Design as part of the Inception phase
    • Design as part of the Requirement phase
    • Working with design libraries
  • The Requirement Phase
    • Definition of Requirements
    • The four levels of Requirements
  • The Development Phase
    • Atomic design
    • Estimations
  • The Test Phase
    • The Definition of Test
    • Types of Test
  • The Operations Phase
    • Release Management
  • The Post Go-Live Phase
    • Incidents
    • Changes
  • Notes
    • My Muses
    • Research

Categories

  • Theme Building
  • Javascript Framework
  • CSS Framework
  • IPS: Pages
    • Database Templates
    • Block Plugin Templates
    • Page Templates
  • Custom Applications
  • Tips & Tricks

Categories

  • Records

Categories

  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Invision Community
    • E-Commerce
  • Miscellaneous
    • Fun
    • Games
    • Inspiration
    • Music

Categories

  • Invision Community HTML Framework
  • Invision Community CSS Framework
    • Typography
    • Colors
    • Columns & Grid
    • Responsiveness
    • Forms
    • Datalists
    • Buttons
    • Messages
    • Miscellaneous
  • Invision Community JavaScript Framework
    • Invision Community UI Widgets
    • Invision Community Utilities modules
  • Invision Community CMS Pages
    • Invision Community Pages Basics
    • Invision Community Pages Templates
    • Invision Community Pages Tips & Tricks
    • Invision Community Pages Basic relationship
  • Invision Community Tips & Tricks

Categories

  • Introduction to The Flexible Atlassian Setup Playbook
    • Design Guidelines
  • How to work with The Flexible Atlassian Setup
    • Portfolio Management
    • Visual Design
    • Requirements
    • Development
    • Test & Acceptance
    • Deploy & Release
    • Post GoLive Support
  • The Jira Software Cloud Setup
    • Introduction to the Setup
    • Issue Types
    • Issue Type Schemas
    • Workflows
    • Workflow Schemas
    • Screens
    • Screens Schemas
    • Issue Type Screens Schemas
    • Custom Fields
    • Field Configurations
    • Field Configuration Schemas
    • Permission Schemas
    • Notification Schemas
  • The Confluence System Documentation Setup
    • Introduction to the Setup
    • Architecture Section
    • Documents Section
    • Instructions Section
    • Quality Section
    • Requirements Section
    • Tecnical Documentation Section
    • Organization Section
    • Visual design Section

Categories

  • Professional
  • Management
    • Methodology
    • Leadership
  • Design
  • Requirements
  • Development
    • Frontend
    • Backend
  • Testing
  • Operations
    • Hosting
    • Security
  • Interesting
  • Atlassian
  • Invision Community
  • E-Commerce
    • CRO
    • SEO
  • Miscellaneous

Forums

  • General
    • Open Forum
    • Support
    • Applications
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Test / QA
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
    • Invision Community
  • Jobs
    • Looking for employee / consultant
    • Looking for Job / Assignment
  • Building The Site's Forums

Categories

  • Jimi's Files
    • Curriculum vitae
    • Presentations
    • Certificates
  • Management
  • Requirements
  • Design
    • Fonts
  • Code
  • Test
  • Operations
  • Atlassian
    • Certificates of Excellence
  • Security
  • Ecommerce
  • Invision Power Services
    • JWSE Support Tickets
    • JWSE Task Management

Calendars

  • Project: JWSE Workboard
  • Project: JWSE Workboard
  • Community Calendar
  • Professional Events
  • Management Events
  • Requirement Events
  • Design Events
  • Development Events
  • Test Events
  • Atlassian Events
  • Operations Events
  • E-commerce Events
  • Invision Community Calendar
  • Events
  • Events
  • premieres
  • Diablo 4 Events
  • Agile 2 Events

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 10 results

  1. Atomic UX Research. Sounds like something amazing, doesn't it? Something that will fit right into the modular design and development processes in Atomic Design. Unfortunately it is just a fancy name for having a proper documentation strategy for UX Research made up by UX Designers who work in poorly structured workplaces. When I first read the article "Foundations of atomic research", I had no idea what the person was talking about. Was it a process, a content strategy or maybe even how to present the findings. I looked up the Atomic UX Research further and found the article "What is Atomic UX Research?" and it seemed like it was all about how to organize the documentation of the findings. I watched the video (added blow) where Daniel Pidcock try to explain this new, revolutionary way to organize data, and I was both amazed and a bit disturbed over the fact that the audience actually seemed to agree with this nonsense. The reason I felt that way is that there is nothing in this new made up word that have anything to do with UX. It's just common sense on how to manage documentation. Any documentation. Anyone working with research should know that you always connect current research with relevant research that it is related to. It is also standard practice for anyone working with research to add metadata to make the research findable in different situations. Anyone working in UX research, especially towards the web, should know that data get old very fast and loose relevance very fast. That is not how you work with any form of documentation that is supposed to be alive. If you make UX research then that data is ever-changing as you continue to learn and experiment. This does not warrant a new way of working, you just need to start working the right way. Proper documentation is always a part of research, as is traceability so you can understand where the conclusions come from and how you used it to formulate new theories to be tested. The Atomic UX Research suggests that you should divide the research into smaller bits and then tag each type with metadata. The idea is that by doing that you can discover other data that is related to your research. If you have hundreds of theories going at once in multiple teams, or you want to bring in similar research on other systems or services then maybe that would be useful. Then again, if you have that many experiments going, then the volume of data would be immense and you would have no way of knowing what data would be relevant. You would spend a ton of time on matching old experiments that probably will be obsolete as the design have already been updated since it was conducted. This is the image used to illustrate the four main parts of the Atomic UX Research. Note that the structure start with the Experiment. Now it may be implied, but an experiment should be tied to a theory. What are we trying to prove and why do we think this is worth exploring should be the starting point for all research. While I think this may be implied, for me this is where this theory fails. By having the theory as the highest level, all experiments fall under that theory. All theories are built on previous learnings so while there is no problem having the information structure dividing the content beyond experiments I think that if you ensure you have your theories in order you would not see many insights related to multiple theories at the same time. Even if you have an additional level of information for insights you would not have multiple conclusions. The conclusion would be tied to the theory we are working with based on the result of the experiments we run to test that theory. In the event that we make findings not related to the theory we are testing, this would be marked in the conclusions as separate theories to explore at a later date. My take on the Atomic UX Research approach is that instead of inventing new names, you should start working with research properly. UX Research follow the same basic structure as every other research field. In order for any research to have the desired effect you need to formulate theories, conduct experiments to test that theory, analyze the result and finally take what you have learned and form new theories and of course activities to improve the service or product you are doing UX on. The result is documented in a searchable tool with metadata and connection to previous theories that support the decision to make further testing of the current theory. You do not need a new methodology for it, just follow the standard research praxis that has worked for many, many years. Doing random exploratory testing is not research. It is exploratory testing/discovery. Atomic UX Research = UX Research.
  2. Atomic UX Research. Sounds like something amazing, doesn't it? Something that will fit right into the modular design and development processes in Atomic Design. Unfortunately it is just a fancy name for having a proper documentation strategy for UX Research made up by UX Designers who work in poorly structured workplaces. When I first read the article "Foundations of atomic research", I had no idea what the person was talking about. Was it a process, a content strategy or maybe even how to present the findings. I looked up the Atomic UX Research further and found the article "What is Atomic UX Research?" and it seemed like it was all about how to organize the documentation of the findings. I watched the video (added blow) where Daniel Pidcock try to explain this new, revolutionary way to organize data, and I was both amazed and a bit disturbed over the fact that the audience actually seemed to agree with this nonsense. The reason I felt that way is that there is nothing in this new made up word that have anything to do with UX. It's just common sense on how to manage documentation. Any documentation. Anyone working with research should know that you always connect current research with relevant research that it is related to. It is also standard practice for anyone working with research to add metadata to make the research findable in different situations. Anyone working in UX research, especially towards the web, should know that data get old very fast and loose relevance very fast. That is not how you work with any form of documentation that is supposed to be alive. If you make UX research then that data is ever-changing as you continue to learn and experiment. This does not warrant a new way of working, you just need to start working the right way. Proper documentation is always a part of research, as is traceability so you can understand where the conclusions come from and how you used it to formulate new theories to be tested. The Atomic UX Research suggests that you should divide the research into smaller bits and then tag each type with metadata. The idea is that by doing that you can discover other data that is related to your research. If you have hundreds of theories going at once in multiple teams, or you want to bring in similar research on other systems or services then maybe that would be useful. Then again, if you have that many experiments going, then the volume of data would be immense and you would have no way of knowing what data would be relevant. You would spend a ton of time on matching old experiments that probably will be obsolete as the design have already been updated since it was conducted. This is the image used to illustrate the four main parts of the Atomic UX Research. Note that the structure start with the Experiment. Now it may be implied, but an experiment should be tied to a theory. What are we trying to prove and why do we think this is worth exploring should be the starting point for all research. While I think this may be implied, for me this is where this theory fails. By having the theory as the highest level, all experiments fall under that theory. All theories are built on previous learnings so while there is no problem having the information structure dividing the content beyond experiments I think that if you ensure you have your theories in order you would not see many insights related to multiple theories at the same time. Even if you have an additional level of information for insights you would not have multiple conclusions. The conclusion would be tied to the theory we are working with based on the result of the experiments we run to test that theory. In the event that we make findings not related to the theory we are testing, this would be marked in the conclusions as separate theories to explore at a later date. My take on the Atomic UX Research approach is that instead of inventing new names, you should start working with research properly. UX Research follow the same basic structure as every other research field. In order for any research to have the desired effect you need to formulate theories, conduct experiments to test that theory, analyze the result and finally take what you have learned and form new theories and of course activities to improve the service or product you are doing UX on. The result is documented in a searchable tool with metadata and connection to previous theories that support the decision to make further testing of the current theory. You do not need a new methodology for it, just follow the standard research praxis that has worked for many, many years. Doing random exploratory testing is not research. It is exploratory testing/discovery. Atomic UX Research = UX Research. View full blog article
  3. Kathy Tavlariou

    Kathy Tavlariou

    Digital expert with extensive experience in driving online sales for well-known global consumer goods companies. What is driving me? Understanding online users behaviour and then turning these insights into increased online sales with high ROI. I am a strong supporter of data-driven mindset and staying always abreast of industry changes. Cross-cultural work environments that are not change-resistant intrigue me the most. Specialties: Ecommerce, AdWords, Content management and SEO, Digital Strategy, UX, Conversion Optimisation, Digital Key Performance Indicators
  4. My assignment was to make a new design for the web based user area based on the graphical profile from one of ChessIT's clients. The design had to be light in terms of changes, as the project had hard deadlines. I worked with the client and the developers to find a balance between the two that satisfied the requirements and respected the time constraints. I also worked with ChessIT to create new icons for their solution and create a design guide for future design work. Furthermore, I assisted with designing a signup form for another client. I also designed the UI for a second system for that same client. These designs I then also ended up coding as well, with focus on CSS and HTML structures. Deliverables in the project: Design in Sketch and later in Figma Client meetings to discuss the designs A new UI for a signup form for another client A new UI for a second system design HTML/CSS for the signup form and the second system Custom Icons Design guideline
  5. How Airbnb drives users’ actions with their landing page design — a UX analysis UXDESIGN.CC There is a reason you are not familiar with many -maybe not even one- of Airbnb’s competitors. The renting/booking marketplace “giant” has… Pretty interesting in how minimalist design reduce cognitive load and drive attention towards CTA.
  6. until
    Welcome to this year's STHLM Xperience Conference. A participatory conference with lectures, practical tips, and workshops. Speakers on stage are experts in their field. You will hear from a Language Consultant, the 'IT Woman of the Year 2015', a Business Developer Manager, a UX Writer, a Digital Designer and many more. And our keynote speaker Katarina Gospic with an M.D., Ph.D. and a M.Sc. in Physiology. You don't want to miss this line-up! Design for the Future We Want Design has a huge impact on people’s lives and the environment. A product or a service can make it or break it very quickly. But what products and services last in the long run? What we design today can have a lasting impact on the world and that means that we need to design for a sustainable future. One part starts with the basic knowledge of our own brain. We need to begin with the understanding of how our brain works, and how it is designed for a time and a lifestyle that we no longer live in. How does digital interfaces, products and services help us in our daily lives and can we combine these with design for a sustainable world? This year's keynote speaker will be talking about how we as humans are going to last in a stressful environment and at the same time be able to perform at top. Date: 14 November 2019 (World Usability Day) Location: Operaterrassen, Karl XII:s torg, Stockholm Time: Doors open at 8:00, conference starts at 9:00
  7. until
    Come to Conversion Jam and get the tools you need to increase your digital results. We hand-pick the world's best Conversion & Growth speakers. A must attend for digital managers and specialists of all kinds: #Analytics #UX #GrowthHacking #AB-testing #Copywriting #FrontEndDev Conversion Jam 2019, the #1 CRO Event | October 8th STHLM STOCKHOLM.CONVERSIONJAM.COM The #1 Growth & CRO event is back! We're bringing you world-class speakers! If you want to know the future of CRO (your job)...
  8. I veckan skulle jag ta mig iväg på bio igen för det är alltid trevligt. Valet föll på SF Biografen Sergel och jag gjorde som jag alltid brukar göra, dvs bokade plats på datorn hemma. Det var då det gick lite snett... På väg genom checkouten så skulle jag fylla i mitt kundklubbsnummer, precis som vanligt. Det tog 3-4 försök innan jag gav upp för trots att jag fyllde i alla uppgifter så gick det inte. Det kom upp en fin varning att jag måste logga in, vilket verkade märkligt när jag aldrig behövt göra det tidigare. Till slut suckade jag högt och klickade på att logga in. Inga konstigheter, jag har gjort det tusen gånger förut men så kom jag fram till steget att sätta ett lösenord och där tog det stopp. Läste informationen flera gånger och försökte få till det, men icke! Helt allvarligt är det inte direkt hjärnkirurgi med lösenord, men läs beskrivningen en gång extra... Lösenordet måste bestå av 8-16 tecken och innehålla minst tre av följande alternativ: Stor eller liten bokstav (A-z), siffra eller specialtecken. Tre av följande...och sedan två set av val. Så jag ska ha tre stora eller små bokstäver, tre siffror eller specialtecken eller är det tre av de olika alternativen små/stora bokstäver, siffror OCH specialtecken? Om du verkligen ska tvinga användarna att sätta ett komplext lösenord, vilket inte på något sätt garanterar en högre säkerhet för systemet och som är riktigt dålig UX, då kan det vara lämpligt att iallafall skriva ut reglerna utan tvetydighet? Efter en hel del svordomar så struntade jag i instruktionerna och satte ett vanligt lösenord och vips så fungerade det. Nu skulle det väl ändå fungera att få koppla ihop min film och njuta av en härlig stund på bio? Nix. Jag fick glatt ignorera det faktum att jag på något sätt kan få poäng trots att jag är inloggad eller att jag ska kunna lägga in mitt biokort manuellt. Inte heller kunde jag utnyttja någon bonus som att jag såg en film före klockan 17 på en vardag. Smidigt som en fisk på fjället med andra ord. Väl på plats gick jag för att hämta ut biljetterna som vanligt, men det gick inte längre. Ingenting på skärmen förklarade varför, men efter lite trixande lyckades jag få ut biljetterna. Nu stod det visserligen i mailet, men jag kikade inte så noga eftersom jag var lite småirriterad redan innan... När man lanserar en ny tjänst som SF Bio har gjort, och det är faktiskt ingen dålig tjänst, så är det viktigt att man testar UX INNAN man går live. Att ha struntfel som otydliga instruktioner eller att inte öra en enkel anpassning i checkoutflödet så jag får information om ändringen och koppla biokortet direkt till min profil så jag kan enkelt logga in i flödet utan att behöva byta vy är bara dålig. Automaten för att hämta ut biljetten kan enkelt visa ett litet meddelande som hjälper besökarna att förstå att ingen biljett behöver skrivas ut och ärligt talat så förstår jag inte varför jag ska ha appen när mailet ska ha samma funktion också. Slarvigt SF att inte lansera en ny bra tjänst ordentligt utan hafsa ut den och därmed skapa lite dålig stämning i onödan. Se till att testa ordentligt nästa gång och gör er UX läxa. Jag hjälper gärna till om ni behöver hjälp för biografupplevelsen är någonting som vi behöver ta vara på för vem vet hur länge vi har förmånen att ha våra biografer kvar? Kan meddela att filmbesöket i övrigt var av högsta klass med fantastisk personal och Sergels fina biografatmosfär. Som alltid.
  9. Årets From Business to Buttons hade ett ganska annorlunda tema där det var mindre fokus på utövandet i sig och mer fokus på ett mer strategiskt och etiskt plan. Kvaliteten var ganska blandad och känslan var mer som en uppfriskande fruktkompott än en premium biff. Det var länge sedan jag fick möjligheten att besöka From Business to Buttons, men det märks att det börjar följa samma trend som ConversionJam, dvs det blir så stort så det är svårt att hålla det på detaljnivå. Årets mix bjöd på både brandtal och lite klichéartade manusläsande. Min upplevelse var att i år var det mer fokus på business än buttons, vilket jag även hörde bland publiken med blandade reaktioner. Låt oss dyka in i kompotten och se vad årets #fbtb2017 bjöd på: Katie Dill Katie bjöd på en häftig resa genom UX strategierna som Airbnb kämpar med och förklarade processen med att hålla ihop de olika journeys som de jobbar med. Budskapet var att släppa tanken på att kunna kontrollera hela resan utan istället se till att ha de processer och verktyg som behövs för att hjälpa andra som är involverade att förstå och därmed bibehålla strategierna. Danielle Ehrlich Danielle tog oss på en häftig resa där hon visade hur design kan påverka och omvandla hela samhällen. Miljö och den personliga kontakten stod i fokus och det var i ärlighetens namn ganska häftigt att se hur design kan lyftas upp på samhällsnivå och få fantastiska resultat. Dawn Ressel Dawn kämpade lite med tekniken och trots årets för mig mest intressanta ämne så föll den ganska platt på grund av att Dawn mer eller mindre läste upp ett manus. Bortsett från en bristande presentationsteknik så hade presentationen ett fantastiskt material som inspirerade stort. Dawn är en sådan fantastisk personlighet också så det var synd att det inte kom fram under just den här presentationen. Jaime Levy Jamie gav ett ganska underligt intryck där några funderade på om hon var full eller hög och första delen av hennes presentation var ganska långsam och bitvis tråkig. Sedan brakade det loss och Jamie visade varför hon är en av världens coolaste UX strateger. Spännande presentation och hon bjöd ordentligt på sig själv så presentationen lyfte rejält. Eric A. Meyer Eric bjöd på ett av de tyngsta budskapen för dagen där han öppnade med en hjärtskärande berättelse om hans dotters tragiska bortgång och hur Facebook öppnade blödande sår med en design som missade att ta i beaktande tragedier. Tungt ämne som berörde och som verkligen behövs i designvärlden där vi fokuserar för mycket på det positiva och ibland glömmer att det finns fler aspekter på våra designbeslut. Mike Monteiro Mike bytte presentation bara någon dag innan och levererade ett brand tal mot fascism och hur vi som designers måste ta vårt ansvar för att motarbeta ondska i världen. Återigen lyftes vi upp på samhällsnivå där vi fick brottas med hur vi ställer oss etiskt som designers. Passionen i presentationen var glödhet och belönades med stående ovationer efteråt. Alan Cooper Alan presenterade via länk och även om man utnyttjade detta till ett ganska roligt inslag med lite försök till magi med presentatören David de Léon så blev det ändå en platt presentation. Trots ett intressant ämne så blev det återigen ett manusuppläsande med ganska märkliga kameraändringar där Alan tittade åt fel håll ibland. Donna Lichaw Donnas presentation var som alltid intressant, men eftersom det är ett sådant väldigt viktigt och ganska komplicerat ämne så upplevde jag att det gick lite fort. För mig som ändå anser mig förstå konceptet så var det ändå inte jättetydligt hur man får fram formeln för UX processer. Tror det hade varit bra att stoppa in lite mer konkreta exempel för de som inte är bekanta med processen så hade presentationen lyfts ännu mer. Alexander Osterwalder Energiknippet från Schweiz lyfte en trött publik med en perfekt blandning av humor och professionalism. Han engagerade publiken tidigt och som alltid ger det bra resultat. Mycket kul presentation och det märktes att många gillade att leka med Business model canvas och value proposition design. En perfekt avslutning som gav energi och inspiration. Över lag så är jag nöjd med årets From Business to Buttons. David och Emma från InUse ledde eventet med precis rätt blandning av humor och professionalism. Hela arrangemanget gick felfritt, informationen var tydlig och det var en bra stämning som alltid. Jag kan varmt rekommendera att du kikar på videofilmerna från eventet när de kommer för det fanns många, många guldklimpar bland årets presentationer. Personligen så var mina favoriter i år Katie Dill, Dawn Ressel, Jamie Levy och Alexander Osterwalder i den ordningen då de var mer hands on. Mike Monteiro, Eric Meyer och Danielle Ehrlich gav de bästa tankeställarna och jag kommer att fundera mycket på deras presentationer framöver.... Var du också på plats och i så fall vilka var dina favoriter?
  10. Jag har jobbat med webbutveckling sedan 1996 och aldrig tidigare har utvecklingstakten när det gäller webbutveckling varit högre än vad den är idag. Nästan dagligen dyker det upp nya frameworks, bibliotek och plugins för att inte tala om antalet editorer som exploderat efter framgången med Sublime och det gäller att sålla hårt för att inte drunkna i utbudet... När jag började med webbutveckling så var det Altavista som var sökmotorn framför alla andra och Netscape krossade IE och dominerade fullständigt bland webbläsare. Idag finns inte Netscape längre och Altavista är ett namn som få av dagens webbutvecklare ens hört talas om och då som en slags mytisk best från en svunnen tid...ungefär som dmoz.org... Då var utvecklingstakten hög och allt verkade vara gjort av lera som förändrades för varje dag som gick och webben fylldes av blinkande texter, animerade marsvin och java applets vackert staplade i tabeller eller frames. Livet för en webbutvecklare var ganska spännande, men samtidigt ganska förutsägbart. Idag är webbutveckling så otroligt mycket mer och en fullfjädrad webbutvecklare måste hantera dussitals olika tekniker med hundratals varianter och varje dag så dyker nya saker upp som måste utvärderas och antingen läras in eller förkastas. Vi ska kunna allt från grafisk design till konverteringsoptimerad UX, HTML5, CSS3 och självklart (minst) 200 olika varianter på Javascript. Vi ska kunna DOM manipulation, optimera kod för att fylla TCP/IP paket så effektivt som möjligt. Vi ska kunna serveroptimering med cache och static content, geolocation, cookies och serversessions. Vi ska smidigt navigera genom JSON, API:er, XML och media queries. Vi ska kunna bygga responsiva webbplatser med skalbar video och grafik och vi ska vara experter på bildformat för optimal prestanda och kristallklara bilder på retina skärmar. Utöver detta finns det mängder av andra saker vi inte bara ska förstå och kunna jobba med utan även följa utvecklingen för allt som sker med samtliga tekniker och alla de tjänster och bibliotek som dyker upp som svampar ur marken. Hur ska man då kunna göra allt detta utan att helt drunkna i den otroliga mängd information som flödar och hur väljer man ut det som man bör fördjupa sig i? För mig så är det enklaste att följa flödet i Feedly där jag satt upp ett stort antal flöden från olika källor. Jag har även en stor mängd källor på Facebook och på Twitter där jag ibland snappar upp nyheter och saker som intresserar mig. När det gäller att välja vad man ska fördjupa sig i så är det betydligt svårare. Det finns tusentals saker att fördjupa sig i och jag brukar kategorisera nyheter som antingen affärsnyttigt, dvs något som kan göra mitt arbete enklare eller snabbare, eller som "nice to know", dvs saker som jag gärna tittar på när tiden tillåter. Det finns en tredje kategori också: slasktratt. Där hamnar oftast saker som antingen saknar information eller som inte utökar en tidigare/liknande tjänst tillräckligt mycket för att vara intressant. Trots detta så är informationsflödet så hårt att det är svårt att hålla sig uppdaterad med allt som sker och även om det svider i mitt hjärta (och min hjärna) att erkänna det så måste det få vara ok. Det går helt enkelt inte att fånga upp och lära sig allt som händer i ett så stort område som webbutveckling är. Det viktigaste är att inte tappa greppet helt och vara nöjd med det man kan för då springer tekniken om en på nolltid...
×
×
  • Create New...