Skip to content

Instantly share code, notes, and snippets.

@justmarkup

justmarkup/thoughts.md

Last active December 30, 2016 17:21
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save justmarkup/c237a5766ef73e1a991576740e125602 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save justmarkup/c237a5766ef73e1a991576740e125602 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. justmarkup revised this gist Dec 30, 2016. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions thoughts.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,12 +1,12 @@
    As 140 chars are not a good way for a discussion, here are my thoughts on a tweet from Jake Archibald https://twitter.com/jaffathecake/status/814751108975489024

    Many clients want *all* the features but only have a limitited (low) budget which in the end often leads to the following scenario.The agency/web company wants the job and promises all the features for the budget, while knowing this way the performance/usability/accessbility will probably suffer. The developers working on the project know they have too little time to add all the features and therefore use tools (frameworks, libraries, plugins...) to reduce developer time and sonehow meet the deadline.
    Many clients want *all* the features but only have a limitited (low) budget which in the end often leads to the following scenario.The agency/web company wants the job and promises all the features for the budget, while knowing this way the performance/usability/accessbility will probably suffer. The developers working on the project know they have too little time to add all the features and therefore use tools (frameworks, libraries, plugins...) to reduce developer time and somehow meet the deadline.

    In the end I think it is often not developer experience, often it is that developers *need* to use available tools to get the job done as fast as possible which often means no time left to improve performance/ux/accessibility. Most developers know that using an unoptimized framework or some plugins probably leads to poor performance/ux/a11y but they need to get their job done.
    In the end, I think it is often not developer experience, often it is that developers *need* to use available tools to get the job done as fast as possible, which often means no time left to improve performance/ux/accessibility. Most developers know that using an unoptimized framework or some plugins probably leads to poor performance/ux/a11y but they need to get their job done.

    The problem is that clients expect too many features and there is always a company doing the job. In the end, they often have
    a site with all the features but with poor performance/usability/accessibility. They mostly don't recognise the problems, because they *only* use their site on their fast devices and fast internet connection.

    I don't know how to solve this but as long as clients think they can get a Porsche with the budget of a Mini there will be Porsche out there which may look like a Porsche but have a top speed of 100km/h and don't work in Winter.
    I don't know how to solve this, but as long as clients think they can get a Porsche with the budget of a Mini there will be Porsche out there which may look like a Porsche but have a top speed of 100km/h and don't work in Winter.

    Some clients may get convinced to reduce features (often not used by any user anyway) and focus on performance/ux/a11y by showing them case studies... but many clients don't care about this, they want to have all the features and think this is the best for users without realizing it may be not.
  2. justmarkup revised this gist Dec 30, 2016. No changes.
  3. justmarkup revised this gist Dec 30, 2016. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion thoughts.md
    View file
    Original file line number Diff line number Diff line change
    @@ -7,4 +7,6 @@ In the end I think it is often not developer experience, often it is that develo
    The problem is that clients expect too many features and there is always a company doing the job. In the end, they often have
    a site with all the features but with poor performance/usability/accessibility. They mostly don't recognise the problems, because they *only* use their site on their fast devices and fast internet connection.

    I don't know how to solve this but as long as clients think they can get a Porsche with the budget of a Mini there will be Porsche out there which may look like a Porsche but have a top speed of 100km/h and don't work in Winter.
    I don't know how to solve this but as long as clients think they can get a Porsche with the budget of a Mini there will be Porsche out there which may look like a Porsche but have a top speed of 100km/h and don't work in Winter.

    Some clients may get convinced to reduce features (often not used by any user anyway) and focus on performance/ux/a11y by showing them case studies... but many clients don't care about this, they want to have all the features and think this is the best for users without realizing it may be not.
  4. justmarkup revised this gist Dec 30, 2016. 1 changed file with 4 additions and 10 deletions.
    14 changes: 4 additions & 10 deletions thoughts.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,16 +1,10 @@
    As 140 chars are not a good way for a discussion, here are my thoughts on a tweet from Jake Archibald https://twitter.com/jaffathecake/status/814751108975489024

    Many clients want *all* the features but only have a limitited (low) budget which in the end often leads to the following scenario.
    The agency/web company wants the job and promises all the features for the budget, while knowing this way the performance/usability/accessbility
    will probably suffer. The developers working on the project know they have too little time to add all the features and therefore use
    tools (frameworks, libraries, plugins...) to reduce developer time and sonehow meet the deadline.
    Many clients want *all* the features but only have a limitited (low) budget which in the end often leads to the following scenario.The agency/web company wants the job and promises all the features for the budget, while knowing this way the performance/usability/accessbility will probably suffer. The developers working on the project know they have too little time to add all the features and therefore use tools (frameworks, libraries, plugins...) to reduce developer time and sonehow meet the deadline.

    In the end I think it is often not developer experience, often it is that developers *need* to use available tools to get the job
    done as fast as possible which often means no time left to improve performance/ux/accessibility.
    In the end I think it is often not developer experience, often it is that developers *need* to use available tools to get the job done as fast as possible which often means no time left to improve performance/ux/accessibility. Most developers know that using an unoptimized framework or some plugins probably leads to poor performance/ux/a11y but they need to get their job done.

    The problem is that clients expect too many features and there is always a company doing the job. In the end, they often have
    a site with all the features but with poor performance/usability/accessibility. They mostly don't recognise the problems,
    because they *only* use their site on their fast devices and fast internet connection.
    a site with all the features but with poor performance/usability/accessibility. They mostly don't recognise the problems, because they *only* use their site on their fast devices and fast internet connection.

    I don't know how to solve this but as long as clients think they can get a Porsche with the budget of a Mini their will be Porsche
    out there which may look like a Porsche but have a top speed of 100km/h and don't work in Winter.
    I don't know how to solve this but as long as clients think they can get a Porsche with the budget of a Mini there will be Porsche out there which may look like a Porsche but have a top speed of 100km/h and don't work in Winter.
  5. justmarkup revised this gist Dec 30, 2016. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion thoughts.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    As 140 chars are not a good way for discussion here are my thoughts on a tweet from Jake Archibald https://twitter.com/jaffathecake/status/814751108975489024
    As 140 chars are not a good way for a discussion, here are my thoughts on a tweet from Jake Archibald https://twitter.com/jaffathecake/status/814751108975489024

    Many clients want *all* the features but only have a limitited (low) budget which in the end often leads to the following scenario.
    The agency/web company wants the job and promises all the features for the budget, while knowing this way the performance/usability/accessbility
  6. justmarkup created this gist Dec 30, 2016.
    16 changes: 16 additions & 0 deletions thoughts.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,16 @@
    As 140 chars are not a good way for discussion here are my thoughts on a tweet from Jake Archibald https://twitter.com/jaffathecake/status/814751108975489024

    Many clients want *all* the features but only have a limitited (low) budget which in the end often leads to the following scenario.
    The agency/web company wants the job and promises all the features for the budget, while knowing this way the performance/usability/accessbility
    will probably suffer. The developers working on the project know they have too little time to add all the features and therefore use
    tools (frameworks, libraries, plugins...) to reduce developer time and sonehow meet the deadline.

    In the end I think it is often not developer experience, often it is that developers *need* to use available tools to get the job
    done as fast as possible which often means no time left to improve performance/ux/accessibility.

    The problem is that clients expect too many features and there is always a company doing the job. In the end, they often have
    a site with all the features but with poor performance/usability/accessibility. They mostly don't recognise the problems,
    because they *only* use their site on their fast devices and fast internet connection.

    I don't know how to solve this but as long as clients think they can get a Porsche with the budget of a Mini their will be Porsche
    out there which may look like a Porsche but have a top speed of 100km/h and don't work in Winter.