반응형
반응형

Principles for Successful Button Design

http://webdesign.tutsplus.com/articles/design-theory/principles-for-successful-button-design/



http://dribbble.com/ormeski/tags/button


1. Matching Brand

It’s important that your buttons match their contextual style. This could mean fitting in with a color palette, graphical style or taking a lead from some form of brand guidelines or logo. Perhaps there are some prominent shapes, textures or design styles that you can pick up on. Maybe a logo has a circular aspect to it and you could pick up on this in your buttons or other potential calls to action.

If an interface predominately uses flat color then perhaps big shiny Apple-like buttons aren’t the way to go. If you can, take the opportunity to experiment with extending the brand through to the interface by using appropriate shapes, effects, coloring or other forms of embellishment.


2. Matching Contextual Style

Following on from above, stop for a moment before opening the ‘UI Elements PSD’. It’s easy to reach for grads, shadows, bevels etc. but take a moment to think whether it’s the right choice not just to match a brand but also the interface in which the buttons sit and whether they need to feel overly ‘buttony’.

Buttons may need to feel particularly button-like within an app and on mobile, for example, but with websites maybe there’s room to do something a little different with your buttons or calls to action.


3. Ensure Buttons Have Enough Contrast

With so many interface designs being inspired by Apple OS styling, particularly in a lot of the UI Element PSD’s out there, buttons can get a little lost amongst other elements being used in the UI, diluting their potentially important power. Try using color, size, whitespace or typography to ensure your buttons have the visual weight they need to stand out from the rest of the interface.


4. Consider Rounded or Shapely Buttons

Following on from the above, if there are lots of other rounded corner UI elements in your design, consider using circular  ended buttons or perhaps some other change in shape. This could give you an extra bit of contrast that ensures your important calls to action have the prominence they may need.


5. De-emphasise Secondary UI Elements

If you’re striving for an OS inspired style or you’re working with a predesigned elements PSD then it’s likely your UI elements will predominantly be rounded corner rectangular in shape. Consider reducing the level of embellishment on elements that can afford to feel less ‘buttony’.


For example, bespoke select menus, segmented controls, custom menu triggers might all be the same rounder corner shapes but using less shadow, border, bevel, gradient or other effects can help to reduce their richness and in turn promote button styles.


6. Color Match Strokes/Borders

Most buttons we see out there have some form of border or stroke on them. Loosely speaking, if your button is darker than the background on which it sits use a dark stroke of the general button color. If the reverse is true then go for a stroke that’s a darker shade of the background color. If you stick with the former and use it on a darker background I find it can make the button edges a little ‘dirty’. Using the latter can also help make your button really pop. I consider this to be a general design principle when dealing with strokes/borders in web design.


7. Be Careful With Blurred Shadows

Over the years I’ve always sworn by my ‘Shadow Law’. The ‘Shadow Law’ states that drop shadows work best when an element is lighter than its background. If an element is darker than its background then drop shadows should be used very subtly. Similar to color matching strokes and borders, I very much consider this to be a general design principle that applies to all UI elements.


8. Subtle Iconography Can Give Affordances

As well as being another small detail that can further differentiate your buttons from similar UI elements, the use of simple iconic elements such as arrows can give some sense of action and a small affordance as to what happens when a user clicks.

For example, an arrow pointing right after the text on a button maybe gives the user some sense of moving on or leaving the page. An arrow pointing down might suggest that some content will be progressively disclosed below, or perhaps some kind of menu will open.


9. Consider Primary, Secondary and Tertiary Styles

If you’re designing an interface where there are consistently lots of actions and functionality on display it may be important to establish some visual language with your buttons by establishing primary, secondary, tertiary and potentially more styles.

Consider reserving the strongest and boldest color for your primary buttons and using progressively less strength or saturation as you reduce importance. As well as color and shade, consider reducing size, whitespace, text size and level of embellishment to further reduce the visual weight of buttons that aren’t primary.


10. Always Make Feedback States

This is a no brainer really, but is often something considered toward the end of the design process. Always work through the core states required for your buttons to ensure they provide the user with sufficient feedback in their context. Users will likely have a mental model of how a button works in the real world as they use it through its various states. Some simple CSS tweaks with shadows, border and gradients and the like can give the user some simple feedback and a touch of eye candy!


Conclusion

As designers you’ll all have your own process you go through. I’ll bet a lot of the time that can involve moving your head back from the screen, tilting it slightly, squinting and saying ‘Yeah that’s about right!’. That’s part of the fun of designing of course and talented designers tend to get it right doing just that, but I think it’s always good to run a bit of internal commentary, interrogating and reasoning over the design decisions you’re making.

There’s no harm in re-using or leaning on pre-designed styles and UI elements, they can obviously save a lot of time. It may even be the case that someone has pixel-perfectly crafted exactly what you were looking for and is offering it for free. However, I don’t think there’s any harm in having a deeper understanding of the design process and craft behind what you’re creating and informing your design decisions going forward.






반응형
반응형

Isotope: An exquisite jQuery plugin for magical layouts

매직컬한 레이아웃을 위한 정교한 jQuery.


Demos

Custom layout modes

Tests



반응형
반응형

jQuery 의 동적레이아웃 플러그인.

A dynamic layout plugin for jQuery
The flip-side of CSS floats.


Masonry is a dynamic grid layout plugin for jQuery. Think of it as the flip-side of CSS floats. Whereas floating arranges elements horizontally then vertically, Masonry arranges elements vertically, positioning each element in the next open spot in the grid. The result minimizes vertical gaps between elements of varying height, just like a mason fitting stones in a wall.


Demos





반응형
반응형

온톨로지(Ontology)

: 사람들이 세상에 대하여 보고 듣고 느끼고 생각하는 것에 대하여 서로 간의 토론을 통하여 합의를 이룬 바를 개념적이고 컴퓨터에서 다룰 수 있는 형태로 표현한 모델.

 개념의 타입이나 사용상의 제약조건들을 명시적으로 정의한 기술이다.

 일단 합의된 지식을 나타내므로 어느 개인에게 국한되는 것이 아니라 그룹 구성원이 모두 동의하는 개념.

그리고 프로그램이 이해할 수 있어야 하므로 여러 가지 정형화가 존재


온톨로지는 일반성 수준이 낮은 것에서 높은 순으로 아래의 네 가지 구분이 될수 있다. 그리고, 추가적으로

 두 가지 다른 형태를 제시할 수 있다. 

  1. 영역 온톨로지(Domain ontology)
    : 전자,의학,기계,디지털 영역과 같이 특정 영역에만 통용되는 지식을 표현한 온톨로지
  2. 메타데이터 온톨로지(Metadata ontology)
    : 온라인 정보의 내용을 기술하기 위한 어희를 제공하는 온톨로지를 지칭한다.
  3. 일반 온톨로지(Generic or common sense ontology)
    : 시간, 공간, 상태, 사건 등과 같은 사물의 기본적 관념과 개념을 제공하는 세상에 대한 일반 지식을 포함하는 온톨로지이며, 결과적으로 이 형태의 온톨로지는 여러 영역에 공통으로 적용될 수 있다.
  4. 표현 온톨로지(Representational ontology)
    : 영역 온톨로지처럼 특정영역을 대상으로 하지 않으며, 무엇을 표현해야 하는지 언급하지 않고 표현개체(representational entities)를 제공하는 온톨로지.

* 추가적인 두가지 온톨로지는 방법 온톨로지(Method)와 과업 온톨로지(Task)다.

   전자는 특정 문제해결 방법(Problem Solving Method)에 제한된 용어(terms)를 제공하고,

   후자는 특정과업에 제한되는 용어를 제공한다.


시맨틱 웹(Semantic Web)

: 현재의 인터넷과 같은 분산환경에서 리소스(웹 문서, 각종 화일, 서비스 등)에 대한 정보와 자원 사이의 관계-의미 정보(Semanteme)를 기계(컴퓨터)가 처리할 수 있는 온톨로지형태로 표현하고, 이를 자동화된 기계(컴퓨터)가 처리하도록 하는 프레임워크이자 기술이다. 웹의 창시자인 팀 버너스 리가 1998년 제안했고 현재 W3C에 의해 표준화 작업이 진행중이다.

시맨틱 웹의 목표

: 지금과 같이 사람만이 웹에 산재한 정보의 의미를 파악하는 것이 아닌, 자동화된 기계가 해석할 수 있는 일종의 표준 의미정보 교환의 수단 이 되는 것이 시맨틱 웹의 목적이다. 시맨틱 웹의 이상향은, 인터넷에 방대한 양의 온톨로지가 산재하고, 이를 자동으로 해석하여 처리할 수 있는 에이전트 소프트웨어에 사람 또는 에이전트가 질의를 하면, 컴퓨터가 자동으로 분산된 온톨로지를 탐색하고 추론하여 원하는 결과를 돌려주는 것이다.


http://www.foaf-project.org/


FOAF is about your place in the Web, and the Web's place in our world. FOAF is a simple technology that makes it easier to share and use information about people and their activities (eg. photos, calendars, weblogs), to transfer information between Web sites, and to automatically extend, merge and re-use it online.

The Friend of a Friend (FOAF) project is creating a Web of machine-readable pages describing people, the links between them and the things they create and do.

반응형
반응형

http://developers.facebook.com/mobile/

Build with Facebook on any Platform

Over 500 million people visit Facebook from a Mobile device each month. Mobile apps that integrate with Facebook provide a fundamentally better user experience.


Getting started

  1. Register your web app
  2. Implement the Facebook SDK
  3. Log the user in

Adding social context

  4. Use the Graph API
  5. Integrate with Social Channels

Deploying your social mobile web app

  6. Display your app properly on devices
  7. Test your integration
  8. Set icons


반응형
반응형

http://techit.co.kr/8757 - 옛날에는 개발을 더 잘했는데… 


http://allofsoftware.net/entry/%EC%98%9B%EB%82%A0%EC%97%90%EB%8A%94-%EA%B0%9C%EB%B0%9C-%EC%9E%98%ED%96%88%EB%8A%94%EB%8D%B0


우리나라 많은 회사들은 소규모일 때 상당히 개발을 잘 하는 것처럼 보인다. 짧은 기간에 꽤 멋진 Software를 뚝딱 뚝딱 잘 만들어 낸다. 이러한 제품이 시장에서 통해서 회사가 성장을 하게 되면 그 이후로 이상하게 개발이 점점 더 어려워지게 된다.


옛날에는 고참 두 명이 이정도의 Software를 6개월만에 이렇게 잘 만들어 냈는데, 지금은 팀원이 10명이나 되고 프로젝트 기간도 과거보다 더 줬는데, 제품의 버그는 더 많고, 제품도 옛날보다 형편 없어 보인다고 한다. 점점 개발이 더 어려워지는 이유는 무엇일까?


두번째 시스템을 만드는 것은 첫번째 시스템을 만드는 것보다 훨씬 힘들다. 두번째 시스템은 첫번째 시스템을 유지보수 하면서 만들어야 한다. 첫번째 시스템에 버그가 많거나 커스티마이징 요구가 많아서 소스코드 브랜치라도 몇 개 존재하면 유지보수에 많은 노력이 들어가서 두번째 시스템에 많은 노력을 들이기 어려워 진다.


또한 두번째 시스템은 첫번째 시스템과 호환성을 고려해야 한다. 두번째 시스템은 첫번째 시스템을 사용하던 고객들의 수많은 요구를 수용해야 한다. 첫번째 시스템은 간단 명료한 기능의 매력으로 인해서 많은 사용자들이 사용을 했지만, 이를 사용하던 사용자들은 계속 요구사항을 요구하게 되고 이러한 요구사항을 적절히 조절하여 수용하는 것이 쉬운 일이 아니다.


두번째 시스템 개발에는 많은 개발자가 투입되고 특히 초급 개발자가 많이 투입되곤 한다. 소수의 개발자끼리 개발을 할 때는 커뮤니케이션 문제가 별로 발생하지 않았는데, 개발자 인원이 많아지면 기존의 주먹구구 방식으로 똑같이 개발을 하면 문제가 발생하지 않을 수 없다. 초급 개발자들은 자기 역할을 제대로 못하는 것 같고, 일이 효과적으로 분배가 되지 않아서 결국 소수의 고참 개발자들이 대부분의 개발을 하는 결과를 초래하기도 한다.

두번째 시스템은 아키텍쳐를 전면 개편하기도 한다. 첫번째 시스템을 개발해 놓고 계속 유지보수를 하면서 사용자의 요구사항을 하나씩 추가해 나가기 시작하면 기존의 아키텍쳐로는 한계라고 불평을 자주 하게 된다. 특히, 첫번째 시스템을 개발했던 개발자들이 퇴사한 상태라면 더욱 더 첫번째 시스템을 비난한다.


그러면서 두번째 시스템에는 완전히 새로운 아키텍쳐를 적용하곤 하는데, 그동안 엄청나게 많은 노력을 들인 첫번째 시스템을 버리고 기능도 몇 배로 많아진 두번째 시스템에 완전히 새로운 아키텍쳐를 적용하면 첫번째 시스템이 시장에서 안정화되면서 겪었던 시간과 노력의 몇 배를 다시 투입해야 한다. 이런 경우 프로젝트가 지연되기 일쑤이고, 출시 후에도 많은 버그와 고객의 불평으로 상당기간 고생을 하게 된다.


그럼, 어떻게 해야 과거처럼 개발을 착착 해낼 수 있을까?


조직이 커졌다면 당연히 시스템과 프로세스가 바뀌어야 한다.

과거에 소수 인원이 개발할 때는 주먹구구식으로 개발을 했어도 문제가 없는 것처럼 보이지만, 사실은 문제가 똑같이 있었는데, 워낙 인원이 적으니 서로 의견을 활발하게 주고 받으면서 문제를 해결해 온 것이다. 인원이 조금만 늘어도 이런 행운은 기대할 수 없다. 조직에 걸맞는 시스템, 프로세스를 적용해서 체계적으로 개발을 해야 한다.


첫번째 시스템도 이런 과정을 거쳐서 체계적으로 개발이 되었다면, 두번째 시스템 개발자들에게 비난을 덜 들을 수 있었을 것이다. 두번째 시스템 개발자들이 완전 새로 개발하려는 이유 중 하나가 첫번째 시스템에 대한 문서가 쓸만한 것이 없고, 아키텍처가 뒤죽박죽이라서 개선을 못하고 버리려고 하는 것이다.


회사가 켜졌을 때 문제 해결 차원에서 시스템과 프로세스를 갖출 것이 아니라, 1,2명이 회사를 시작하더라도 체계적으로 개발하는 것이 가장 좋은 방법이다. 이미 첫번째 시스템은 점점 뒤죽박죽이 되어가고 조직은 엉망이라면 시스템과 프로세스를 갖추는 일이 먼저 필요하다.

반응형

+ Recent posts