ウェブサイトは何でできているか(wdt連載1)

実は意味不明の文字ばっかりなんです・・・・・

ここで、「ウェブサイトはHTMLとCSSとJavascriptでできています!」と、迷わず即答できた方は、途中を読み飛ばしても大丈夫です。(お時間ありましたら、最後の方だけ読んでいただければ幸いです。)

厳密には、バックエンドにあるものとか、色々あるんですけれども、とりあえず、この記事では「見える範囲のこと」でお話進めさせていただきます。

文字ばっかり?しかも意味不明の??
なんのことですかそれは、と思った新人デザイナーの方、すみません、今回は、デザインの話よりも、ウェブサイトが何でできているか?という話です。でも、これを知っているのと知らないのとでは、今後の仕事のしやすさに、質に関わってくるので、もうしばらく、辛抱してお付き合いください。

あ、この先食べ物で例えるので、お腹の減っている方は閲覧注意です!

では「カレー」に例えてみましょう

唐突ですね。いつかの私の朝ごはんです。
カレーがウェブサイトある1ページだとしたら、HTMLとCSSとJavascriptって大体どの辺りのことだろう、というのを例えてみたいと思います。

玉ねぎ、ニンジン、ジャガイモ、肉(つまり具材):HTML
カレーのルー:CSSやJavascript

ざっくりですね、はい、ざっくりです。
この話の、何がツボかというと、同じHTMLでもカレーのルーにあたるCSSやJavascriptを変更すると、別の見た目に変えることができるということです。シチューのルーに変えたり、醤油とかみりんに変えれば和風に、というふうに、見た目や振る舞いが変わります。
でも、具材であるHTMLは、一緒。

余談ですが、出来上がったものが、カレーなのかシチューなのかぐらいは、人工知能のようなものでも判断できそうですけど、美味しいかどうかは人間にしか判断がつかないんじゃないかなあ、と思っています。カレーのルーを入れたら大体美味しくなる、っていうのが現実かもしれないですけど、本当のところの「美味しい」を決めるのは、具材自体が美味しいのが一番であろうな、と思っています。

HTMLってなんですか?

具材になるHTMLというものがどういうものか、ウェブサイトを見ながら、割と簡単に見てみることができます。

ウェブサイトを開いて、ページ上で右クリックします。すると、「ページのソースを表示」というような内容のメニューがあるので、それを選びます。

すると、下記のような、文字列が表示されると思います。

これが、HTMLです。何この呪文・・・・と若干引いても仕方ないです。意味がわからなくても構いません。最終的に完成したウェブサイトが、こういうものでできているということを覚えておくだけで、今のところ大丈夫です。
とはいえ、もう少しだけ、分かりやすそうなところを選んでみますね。

このページを見てみます。http://www.ccc-labo.net/blog/2016/02/post-156/

画面左側が、実際のサイトの表示で、右側がHTMLです。
左側に見える記事のタイトルや本文部分が、右側にあるHTMLに同じ部分が探せますでしょうか?

こんなふうに書いているHTMLが、CSSやJavascriptで味付けされて、ウェブページに仕上がっていく、というわけです。

CSSやJavascriptを見てみる

HTMLに比べて、CSSやJavascriptを実際のサイトで見てみるには、少々技が必要なのですが、細かいことなので今回は省きます。

CSSはこんな感じです。

ウェブサイトの見た目のほとんどはHTMLをCSSで装飾することでできています。
この画像に書かれているのはほんのわずかのことで、CSSは全体のレイアウトや、カラーリング、枠線、角丸やドロップシャドウなど細部の装飾も引き受けています。

Javascriptはこんな感じです。

これは、スマホで見たときに、メニューを右からスライドして表示させる部分のスクリプトです。Javascriptはこのように、ボタンをタップしたときに動いたりアクションをさせる、スライダーを動くようにする、などユーザーの操作に従って何か動く、変わる、という部分を引き受けています。

これを書くのはとても無理だ!・・・・と思って、正解です

デザイナーを目指している方にとっては、無理で当たり前です。これを書けるようになるというところを目指す必要はありません。別の仕事ですので。ちなみに、この記事を書いている私は、このわけのわからん文字列を書くのを仕事にしている人です。

でも、最終的にこういうものになって公開されている、ということだけは、ぜひ知っていてください。と、同時に、ウェブサイトを作るというとき、デザインというものは、とても、とても大事ですが、それだけでウェブサイトが出来上がるわけでは絶対にないということをわかっておいて欲しいです。

こういう文字列を書いてウェブサイトを仕上げる人を、コーダーとかフロントエンドエンジニアとか、言います。今回は話に出ませんでしたが、ウェブサイトを作るには、その裏の仕組み(フォームの送信だとか、管理画面を作って記事を投稿できるようにするだとかいうもの)を作る人がまた別にいて、それらはバックエンドとか呼ばれ、また専門的な知識を持つエンジニアさんやプログラマさんがいらっしゃいます。
さらにさらに、ウェブサイトを公開するためには、サイトにアクセスするためのアドレス(ドメイン)を取得・管理したり、ウェブサイトを公開する場所(サーバー)を借りたり、など、など、いろんなことが関わっています。

ウェブサイトは分業で成り立っている

デザイナは、これまでに挙げたことに、関わることもあれば、関わらないこともあるでしょう。けれど、ウェブサイトを作って公開するまでには、何が必要で、何を考えなければいけないか?ということぐらいは、知っていて損はありません。
この連載は、それを知る助けになるように、書いています。

デザイン以外のところは、誰かに頼むしかないのがウェブサイトの制作です。そのときに、相手がどんなことをしている人なのか、全く知らずに頼むのか、概要の概要ぐらいはわかっていて頼むかでは、頼まれた人の対応も違う、ということをわかっていて欲しいです。
ですが、周りを見渡すと、コーディングやプログラムについて知っているデザイナさんはほぼいませんし、もちろん、コーダーやプログラマもデザインについて知っているとは言い難いです。それぞれの立場の人が、もう少し視野を広げて自分の分野以外のことも、多少は、知っているのがいいんだろうな、というのが常に思っていることです。

ですが、それがとても難しいことも、よく知っています。
デザインも、コーディングも、プログラムも、それぞれの分野がとても底の深い世界で、勉強しても次々新しいものが出てきて、また勉強し直さなきゃならない、という世界ですので。

デザインとウェブサイトは対象の本質に迫るもの

さらに言うと、デザインそれ自体が、対象とするものに深く切り込んでいくものであるように、そのデザインを体現するウェブサイトも、対象に深く切り込んで出来上がるものだと思っています。
対象が、例えば企業であれば、その企業の成り立ちややってきたこと、これからのこと。ブランドやサービスであっても、それらの本質をつかむことから始まるのではないかと思います。そうなれば、経営やビジョン、戦略といったものと、デザインやウェブサイトが切り離せないことも、意識していただけたらと思います。ウェブサイトに、マーケティングや企業戦略という言葉がついて回るのは、そのためなのです。

ウェブサイトは何でできているか?

最初に、ウェブサイトはHTMLとCSSとJavascriptでできていますとか、書きましたが、それだけではないということも、おわかりいただけたかと思います。

デザイナであれば、ウェブサイトの見えるところだけを扱えばいい。そういう考え方も、もちろんあるでしょうが、ぜひ、発想を逆にして欲しいと思います。

今から作ろうとするウェブサイトは何でできているか?

具材、という話をしましたが、調理すべき具材とは何でしょうか?企業サイトであれば、その企業はどんな具材なのか?何を伝えなければならないのか?その為には、どんな料理に仕上がっていけば美味しさを伝えられるのか?これは、いつ、どこで、どのように伝えられれば、ユーザーにとって最適なのか?考えるべきところは、実はそういうところにあるのではないかと思います。

今すぐでなくてもいいですが、良いデザインは、深いところから表層へ向かっていくような流れで、作られていくものかなあ、と思います。

小難しくてすみません・・・・

連載の第1回目から小難しい話でした。このように、こ難しい話もしますが、わかりやすーい、明日からすぐ使えそうな話も、この先、しますので、ぜひこの連載にお付き合いください。

[ssba]

Photoshop のWeb用に保存はまだ使える、という話

AdobeCCのどのバージョンか忘れましたが、「Web用に保存」機能がメニュー直下から見えなくなっていました。

いつもショートカット使っているので意識していなかったのですが、よく見たら「Web用に保存(従来)」とかがついて、あら、もう古いってこと?って感じなのです。

しかし。使って欲しい、この機能。

なぜなら、「Web用に保存」とするだけで、下記のことができる。

  • CMYK画像もRGBに変換、sRGBにもできる
  • カラープロファイル消せる
  • メタデータを消せる(部分的に残す設定も可能)
  • 72dpiに変換

これ、いっこいっこやろうと思うと結構大変ですし、慣れてない人ならなおのこと。
ファイルの容量も画質を落とさず軽くなります(カラープロファイルとか余計なメタデータが容量を食う場合もあるみたい)
うっかりCMYKになってない画像を作っちゃうぐらいだったら、リサイズ・トリミングしたあと、保存するときにコマンド+オプション+シフト+Sでできちゃうんだから、これ使う方がいいと思うんです。

続きを読む Photoshop のWeb用に保存はまだ使える、という話

[ssba]

データベースのバックアップの時に気をつけていること

WPサイトのアップデートは必ず対応しましょうね〜、と布教しております、管理人です。

今回は、アップデート時に欠かせないWPのデータベースのバックアップについて、気をつけていることを書き留めておきます。

バックアップの手順については、前にも書いたので、こちらを参考にしてください。

WPのアップグレードに併せて、バックアップと更新手順のおさらい

今回は、データベースを書き出す時に、容量に注意した方がいいですよ、というお話です。WPサイトの運用時間が長くなれば、記事も多くなり、データベースのデータ量も大きくなっていきます。また、管理画面のログを取る、404エラー表示のログを取るなど、何かしらログを残す系のプラグインが入っていて、設定を特にしていなくてひたすらログが残っていくような仕様だった場合、ものすごくデータが大きくなったりします。

それでも、データベースの「エクスポート」が失敗する、ということはめった経験がありません。なので、数十MBぐらいであろうと、気楽にエクスポートしてしまいます。

そこから、悲劇が起こりました。

スクリーンショット 2016-07-15 13.32.14

いざバックアップデータを使って復元を試みるも、インポートできるファイルの容量には制限があります。この場合は16MB。エクスポートしたファイルがこれより大きければ、読み込めません。圧縮しまくってアップする、という方法も聞いたことありますが、明らかに無理な時も、あります。また、これは接続環境にもよるのかもしれませんが、あまりに膨大なデータをアップしようとすると、途中で読み込みが止まってしまったりで進まずイライラ、ということがよくあります。
と、いうわけで、エクスポートの段階で小分けしておく方が幸せ、というのが気をつけていることです。

エクスポートするときデータベースのテーブルを見て容量の大きいテーブルについてメモっておきます。次に、エクスポートの画面で、エクスポートの対象からそれらの容量の大きいテーブルを外してからエクスポートします。次に、データの大きかったものを別々にエクスポートします。(経験に基づくだけですが、まとめるより1個ずつの方がいいみたいです。)

スクリーンショット 2016-07-15 13.35.01

そしてエクスポートしたものを、ちまちまインポートすれば、オッケーです。

このとこと、WPサイトを引越しさせたり、テスト環境ように複製したり、ということが続いていて、とにかくFTPでダウンロード、アップロード、の作業に時間がかかりまくりで非常にストレス。。。と思っていたのです。

そして見つけた。こんな記事。

WordPress の引っ越し方法色々
https://dogmap.jp/2013/01/15/wordpress-migration/

SSHっちゅうのがまずわからないけど、要はターミナルでモニョモニョって話よな・・・と、へっぽこノンプログラマなので、黒い画面とかできればお近づきになりたくない・・・。お客さんからはYOUやっちゃいなよ、的に言われたこともありますが、固く、お断りしました。わからんやり方で触れませぬ・・・。

でも、時短したいので、誰か教えて欲しいです。(切実)

[ssba]

Sass勉強会の大雑把な内容(2016.5.15)

勉強会にあたって、下記の書籍を購入しました。
Sassを書いてみたい方にとてもオススメです。
Web制作者のためのSassの教科書
サポートサイトで書籍の正誤表やサンプルソースを見られます→http://book.scss.jp

さて、勉強会のために、下記のページを作りました。
http://www.ccc-labo.net/_demo/sass_lesson1/local/
このページを作る際に書いたSassを例にしてSassの基本的な書き方を確認していきました。

なお、コンパイル結果を確認するために、ウェブツールを使いました。
SassMeister→http://www.sassmeister.com

最初に、Sassの使い所がイマイチない、という話をした。そもそもCSSを書くときの管理方についても明文化できていないのに、Sassを使って効率化、という段階にない、とか、自分がSassで書くと他の人に引継ぎができないとか。そもそも、プログラムアレルギーが強くて馴染めない、などなど。

これらは私がSassを遠ざけた理由そのままだったので、とても納得なのだが、改めてSassをいろいろいじってみると・・・・・・まあ、圧倒的に便利な部分がある。例えば変数とかは使いたくてたまらない。コンパイルとか、環境を作ることがまず大変ですが。。。(苦労しました)
この苦労と、書き方を覚える労力をかけるのと、今まで通りCSSをサクサク書くのと効率としてはトントンかもなあ、という思いがSass導入を遠ざけていたわけです(個人的に)。
しかし、勉強会を機に、一旦コンパイルする環境まで作ってしまえば、逆にこう思った。

「Sassのファイル内でいつも通りCSS書いたらそれは単純にCSSとして書き出されるだけなんだし、Sassの便利なところ、書ける!と思うことだけ取り入れたらええやん。」

と、いうわけなので、楽しいです、Sass。
紹介した書き方が下記です。カキカキ。

入れ子

.entry-header {
	.entry-title {
		font-weight: 300;
		text-align: center;
	}
}


.main-navigation {
		
	ul {
		padding: 0;
		margin: 0;
		text-align: center;
			
		li {
			display: inline-block;
			margin-right: 10px;
			line-height: 1;
			
			a {
				display: block;
				padding: 7px 10px;
				background-color: #333;
				color: #fff;
				text-decoration: none;
				transition: opacity 0.5s ease-in;
				opacity: 1;
					
				&:hover {
					opacity: 0.6;
					transition: opacity 0.5s ease-in;
				}
			}
			
			&:last-child {
				margin-right: 0;
			}
		}
	}
}

 

変数

$window_medium : 600px;
$window_large : 1200px;

$keycolor : #007099;

 

計算と繰り返し
@for関数を使って、繰り返しの処理を書く。

$grid_margin : 2%;/*単位は%*/
$grid_width : ( 100 - $grid_margin * 5 ) / 6;

@for $i from 1 through 6 {
		.grid-small-#{$i} {
			width: ($grid_margin * ($i - 1) + $grid_width * $i);
		}
	}

 

色の計算
キーカラーから派生させた背景色を作る。こうするとトーン配色を守った色使いが考えやすい。

$keycolor : #007099;

.main-visual {
	text-align: center;
	background-color: mix($keycolor,#EEE, 10%);
	padding-top: 40px;
	margin-bottom: 30px;
}

 

@extendの例
同じ処理をまとめるために使う。ただ、後に紹介する@mixinの方がSassで書くものとコンパイルの結果の違和感が少ないよね、という意見もあった。(私もちょっと苦手)

%btnBase {
border-radius:3px;
background-color: #333;
color:#fff;
}

.btn {
@extend %btnBase;
padding: 9px;
}



.item {
@extend .btn;
margin-left:10px;
}

.item2 {
@extend %btnBase;
margin-left:10px;
padding: 4px;
}

ミックスイン
@mixin関数。これは本当に便利だ。
@include kadomaru(); のカッコ内には角丸のサイズを入れることで、変更ができるので試してみてほしい。
例 @include kadomaru(10px);

@mixin iblockHack {
	display: inline-block;
	*display: inline;
	*zoom: 1;
}

@mixin kadomaru($value: 4px) {
	-moz-border-radius: $value;
	-webkit-border-radius: $value;
	border-radius: $value;
}

li {
				@include iblockHack;
				margin-right: 10px;
				line-height: 1;
a {
					display: block;
					padding: 7px 10px;
					@include kadomaru();
}
}

 

ミックスイン複数の値
複数の値をとることも可能。角丸のサイズとパディングの値を変数にしておくと、これひとつで角丸のあるボタンやボックスの調整がたった1行書くだけでできるようになる。

@mixin kadomaruBox($value1: 4px,$value2: 10px) {
	-moz-border-radius: $value1;
	-webkit-border-radius: $value1;
	border-radius: $value1;
padding: $value2;
display: block;
}

a {
@include kadomaruBox(10px,30px);
}

以下、勉強会の時に出てきた質問などについて少し調べておいたので、書き留めておきます。

コンパイルされたCSSの改行とかタブの入り方が気にくわない、修正したい!
こんな記事見つけました。やっぱり思っている人はいた。
http://www.ysakmrkm.com/2012/10/customize_output_format_compiled_by_sass.html
根本的な解決にならない、って書いてあるけど、どうじゃろ、ruby詳しい人に聞けばいいのかな・・・。

Macでの環境構築について
El Captainになって、OSのシステム系のファイルにルート権限でもアクセスできなくなったそうな(すみません、細かいことはよくわかっていません)。
で、Macは標準でRubyが入っているからそっち使ってもいいよ、という感じでやってみようとしたんですが、失敗しまくり。色々やりすぎて何をどうしたのかあまり覚えてもいない・・・・・。
この辺りが参考になる気がします。
https://teratail.com/questions/23280

compassを使う
勉強会の際に使っていたMacBookではできなかったのですが、自宅のiMacでは普通に使えたので、頭を抱えています。バージョンとかも変わらないのですが・・。
ただ、iMacの環境では、compass watchがなんだかうまくいってない風・・・・。謎です。。。。。
これについてはまた何かわかったら書きます。

[ssba]

投稿の「この投稿を先頭に固定表示」を使ってみた

スクリーンショット 2016-02-11 22.18.09

そういえばこんな機能あったな、と思って使ってみた。
特別設定が必要なわけじゃないのかなー、という感じです。

スクリーンショット 2016-02-11 22.25.23

上記は投稿一覧のページです。特に設定した覚えはないんですが、投稿の一覧のページでは先頭に表示されていました(右サイドのRecentが本来の投稿順の記事の並びです)。メインクエリだと特に何も設定しなくても使えるのかなあ、という感じです。
先頭に固定した記事が複数あるとどうなんかな。

ですが、フロントページで、get_posts()とかで記事を呼び出すときとかは、先頭に固定したからといってそれが反映されるわけではないです。

なんかもうちょっといい方法があるような気がしますが、とりあえず、最初に「先頭固定表示の記事のみ」を表示して、そのあとに「先頭に固定表示の記事以外」の記事を呼び出している、という感じにしました。

		<ul class="front-news-list">
<?php
$sticked_posts = get_posts( array( 'post__in' => get_option( 'sticky_posts' ), 'posts_per_page' => -1 , 'post_type'=> 'post') );
foreach ( $sticked_posts as $post ) : setup_postdata( $post ); ?>
		<li class="list-item sticked-item"><time class="date"><?php the_time('Y-m-d');?></time><a href="<?php the_permalink();?>"><?php the_title(); ?></a></li>
<?php endforeach; wp_reset_postdata();?>
<?php
$args = array( 'post__not_in' => get_option( 'sticky_posts' ), 'posts_per_page' => 5 , 'post_type'=> 'post') ;
$myposts = get_posts( $args );
foreach ( $myposts as $post ) : setup_postdata( $post ); ?>
		<li class="list-item"><time class="date"><?php the_time('Y-m-d');?></time><a href="<?php the_permalink();?>"><?php the_title(); ?></a></li>
<?php endforeach; wp_reset_postdata();?>
		</ul>

実際の表示は下記の感じです。

スクリーンショット 2016-02-11 22.37.33

参考になればと〜。

[ssba]

サイトの文字化け、大丈夫ですか?

Twitterなどで「あの公共施設のサイト、文字化けしてるぜ」「スマホで文字化けしている」という書き込みを最近よく目にします。
というのも、PCのブラウザでは文字化けが「減った」のですが、スマホで見ると文字化けを起こすサイトが「増えた」ようなのです。

文字化けをしてしまっている場合は、サイトのソースに、下記のような一文が入っているかどうかを確認してみてください。

<meta charset="UTF-8">

少し書き方にばらつきがあるかもしれませんが、charsetの部分がキモです。
これが入っていないサイトが文字化けせずに見えていたとしても、それは「たまたま」ですので、正しいコードを入れるようにしてください。(これが入っていて文字化けする場合は、もうちょっと複雑な原因も考えられますので、即、サイト制作者に相談してください。)このコードは「このサイトはUTF-8っていうエンコードで書いてあります!」という宣言になり、ブラウザはこれを見て、適切な解読をするわけです。

上記のコードはあくまでこのサイトの場合ですので、それぞれのサイトで適切なコードは異なりますので注意してください。必ずホームページの制作者などに問い合わせてください。その時は「サイトが(スマホで見ると)文字化けするので、文字エンコーディングのメタタグを確認してください」とお願いするといいと思います。

最近のサイトは、概ね「UTF-8」という文字エンコーディングが使われている場合が多いですが、ひとむかし前は「shift-JIS」という形式が多くありました。
文字エンコーディングを示すメタタグが書かれていない場合、ブラウザは当てずっぽう(と言ってもかなり精度の高い当てずっぽうではあるのですが)で解読をします。たいてい「あたり」のエンコーディングにたどり着くので文字化けをせずに表示されるのですが、スマホのブラウザでは「失敗」がもしかすると多いのかもしれません。そもそも宣言をしていないと正確なエンコードは「わからない」ものなので、先に挙げたコードが入っていないといけないです。

文字化けをするサイトが増えてきているのは、潜在的にあった「文字エンコーディングのメタタグが抜けているサイト」が、スマホの普及と閲覧者の増大によって表面化してきた、ということなのかなあ、と思っております。

みなさま今一度、自分のサイトを確認してみてくださいませ。

[ssba]