SEOとUXから考える、優れたサイトストラクチャー（サイト構造）の条件とは？ - デジタルマーケティング入門ガイド
SEOとUXから考える、優れたサイトストラクチャー（サイト構造）の条件とは？ 2020年4月26日 2021年6月11日 SEO（検索エンジン最適化） digital-marketing Webサイトの新規開発やリニューアルを行うとき、サイトストラクチャー（サイト構造）をイチから考える必要に迫られます。そのような時、皆さんならどのような方法論で検討を進めるでしょうか？ ほとんどの場合、サイトストラクチャーを検討する上で考慮しなければならないのは、SEO（検索エンジン最適化）と、UX（ユーザー体験）の2つの観点だと考えられます。 企業内のクローズドなWebサイトなどを除いて、通常のWebサイトならSEOを考慮し、検索エンジンからの流入を図ることは最優先事項の1つです。 また、そもそもWebサイトを公開するからには、Webサイトを通じて達成したい、何らかのビジネス上の目的があるはずです。その目
5つのサイトストラクチャ（Webサイト情報構造）を実際のサイトと照らしあわせて考える
2012年 08月 24日 5つのサイトストラクチャ（Webサイト情報構造）を実際のサイトと照らしあわせて考える カテゴリ： IAシンキング Webデザイン タグ：IAシンキングWebサイト構築 サイトストラクチャとはWebサイトの構造のことです。サイトストラクチャを考える際には、作るサイトの目的に合わせた設計が必要なのは言うまでもありません。では、その目的に合わせた設計とはどういうものでしょうか？それを考えていきたいと思います。 1.サイトストラクチャ（サイトの構造）パターンについて 2.5つのパターンの解説 3.サイトの全体像と部分的な構造 サイトストラクチャ（サイトの構造）パターンについて Webサイト制作にあたり、サイトの設計で多く採用されるものとして5つパターンがあります。 階層型分類構造 ファセット型構造 Web型構造 直線型構造 ハブ＆スポーク型構造 名称だけを見てもピンと来
Material Designの設計思想を探る｜usagimaru
この記事は、2018年5月25日に開催された Google I/O Extended 2018 Shibuya での講演内容を文章に起こしたものです。当時はGoogle I/O 2018の直後、Material Designガイドラインがいくらかアップデートされ、Material Themingや柔軟な基盤の構築といった新たな考え方が明示されたばかりでした。この講演は、アップデートされた内容の背景にある思想や意図を考察し、Material Designの動向を探ろうという趣旨になります。この記事では当時のスライドを交えながら内容の解説と考察を行います。 今回は、I/Oで明らかになったMaterial Designの新しい部分を中心に、iOSのデザインと比較しながらその設計の仕組みや思想を探っていきたいと思います。異なる観点から向き合うことで共通点と他との差異を見極めるという方法をとります。
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
プログラマの抱いている名前についての誤謬
パトリック・ミッケンジー（Patrick McKenzie）さんのブログ・エントリ、 “Falsehoods Programmers Believe About Names” の日本語訳です。翻訳の公開を快諾してくださったミッケンジーさんに感謝します。 公開: 2012-02-22 Posted on June 17, 2010 by Patrick きょう、ジョン・グレアム゠カミング（John Graham-Cumming）が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
読み放題をやめたらアプリの収益性3倍に。チャット小説の「peep」が語る、サブスクの読み放題から「強いIP」が育たない理由と、ボタン文言変更で収益性1.2倍になった話｜アプリマーケティング研究所
読み放題をやめたらアプリの収益性3倍に。チャット小説の「peep」が語る、サブスクの読み放題から「強いIP」が育たない理由と、ボタン文言変更で収益性1.2倍になった話 300万ダウンロードのチャット小説アプリ「peep」さんにお話を伺いました ※ taskey株式会社 CEO 大石 ロミーさん、CTO 深見 将一さん、peep事業推進部 部長 相澤 一樹さん「peep」について教えていただけますか？相澤： peepという、e-Storyアプリ（チャット小説）を運営しています。ダウンロード数は300万を超えていて、2,000作品が掲載されています。 ユーザー層は「22歳まで」が60％と若くて、iOSが80％くらいを占めます。現在は40名ほどで運営しています（インターンや業務委託を含む） どのような経緯で「peep」が生まれたのですか？大石： もともとは「世界でヒットする作品」を生み出すことを
Railsをやめても解決しない問題
序文 昨年末くらいからRailsとフルスタックJavascriptの論争の記事がよくバズってましたね。主にORMとパフォーマンスやSPAが論点として多かった気がします。 Rails側のSPA作りづらい問題に対し、hotwireが一つの解として今後どういう受け入れ方をされて行くのか、どう発展していくのかは気になるところです。 未来のフルスタックフレームワークの代表争い さてこの論争、僕は「未来のフルスタックフレームワークの代表争い」だと思っているのですが、結構難しくって視点次第でどうとでもなっちゃうような気がしてます。 というのもこの手の技術選定の問題ってアプリケーション規模やチームの思考、求められるサイト特性などによって合う合わないがあるので、一概に正解がわからないんですよね。 例えば今勉強がてらブログを作ってみたい、という人には迷わず僕はblitz やNext/Gatsby＋外部サービス
最近のモダンなWebサービス開発の構成について調べるメモ
ここのところ雑にWebサービスをリリースする機会が減って最近はFlutterでネイティブアプリばかり書いてるのでWebの最新に追いつけてない。 最近の流行りのWebサービス開発について自分の必要そうな範囲でちょっと調べてみる。 自分の場合、フロントエンドはTypeScript+(Vue or Nuxt)でやって、サーバーサイドはRailsで書いちゃうことがまだ多い。 これでもなんとかなるけど、もうどうせならJSで一気通貫でフロントエンドとサーバーサイドを書ければ楽なのにと思いつつある。 パッと思いつくのはTypeScriptでフロントエンドをNext,Nuxtあたりでやって、バックエンドAPIをexpressとかサーバーレスAPIを適当に書くとかだけど、今だともっと良い方法ありそう。 本当はDartでサーバーサイド、FlutterでwebまでいければDart統一時代になって願ったり叶ったり
5年間 Laravel を使って辿り着いた，全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころ
この記事は Laravel Advent Calendar 2020 - Qiita 最終日の記事です。 TL;DR DDD や "真の" クリーンアーキテクチャは， Web 業界における大抵の現場ではオーバースペックだし，導入しても全員がついてこれるとは限らない app/UseCases ディレクトリだけ切って，ドメインごとに単一責務なクラスを置くと使いやすいよ ActiveRecord 指向のフレームワークで Repository パターンを無理に導入すると死ぬので， UseCase で Eloquent Model の機能を使うことを恐れるな はじめに Zenn では初投稿です。日本の Laravel コミュニティではもうお馴染みのようで実はあまり顔を出していない（？） @mpyw と申します。オンラインサロンの火付け役となった Synapse が最初の仕事でしたが，就職後すぐ会社が
成功法則が詰まったBtoBサイトの標準ワイヤーフレームを無料配布します | knowledge / baigie
約1年前、BtoB企業における顧客獲得型サイトの勝ちパターンをまとめた『BtoBサイト・チェックリスト』を、ベイジ、才流さん、WACULさんの3社連名で発表し、大きな反響をいただきました。 このチェックリストはブログで公開しただけではなく、私たちのウェブ制作の現場でもフル活用されています。この1年間に手掛けた多くのBtoBサイトが、このチェックリストを満たすように設計され、多くのBtoBサイトでコンバージョン数/率やフォーム誘導数/率の向上など、ポジティブな変化が生まれました。 このような活動の中から、『BtoBサイト・チェックリスト』の内容を満たした『BtoBサイト・ワイヤーフレーム』なるものが誕生しました。これを今回、皆さんにご提供します。リード情報なども一切取らず、そのまま丸ごとお渡しします。 BtoBサイト標準ワイヤーフレームXD版（770KB） BtoBサイト標準ワイヤーフレーム
WEB アプリケーション設計入門 / Introduction to web application design
PHP Conference Japan 2020 トーク前提の資料です。そのため、トークがないと理解が難しいかもしれません。 https://youtu.be/UTKJ-Lgn3aI?t=36 ※冒頭音声が小さいです。マイクを手に持ってから聞こえやすくなると思います。 資料中の ADOP については下記を参照ください。 https://nrslib.com/adop/ # Abstract https://fortee.jp/phpcon-2020/proposal/da5b9d99-e5a6-4f51-adea-1f1c10d99020 # Ref https://github.com/nrslib/scrum-app-sample-php https://github.com/nrslib/repository-support-php # URL Togetter: https://
技術的負債の優先順位について論文を読んでみた
はじめに POLプロダクト Advent Calendar 2020の8日目のバトンを受け取りましたので、技術的負債の優先度について考えてみます。 技術的負債の認識とその対策が非常に重要であることは、エンジニア以外の方々にとっても、認識されつつあると思います。 技術的負債と呼ばれるものは非常に多岐に渡り、どのような会社においても大量に存在するでしょう。 私自身もエンジニアとして大量の技術的負債を作ってきた自覚があり、またどなたかの技術的負債に向き合ってきた経験があります。 しかしながら、ではどの負債から返すべきなのかということは、私の中にも確固たるロジックがありませんでした。 今回はこの問題を掘り下げるべく、ある文献レビュー論文を追いかけ、その中で紹介されていたわかりやすい方法を紹介します。 技術負債とはなにか？ 技術的負債はWard Cunninghamさんが1992年に国際カンファレン
BtoBなソフトウェア開発における必読書3選 - Runner in the High
BtoBなソフトウェアの開発において業務知識なしにシステム設計をすることはほぼ不可能に近い。 これまで、業務支援系のシステム開発はSIer企業たちのお家芸であったが、近年ではWeb系のベンチャー企業やスタートアップであってもこれまでSIerが担っていたようなドメイン領域で戦うことが増えている。 「会計処理」「流通管理」「在庫管理」「人事管理」あたりのドメインにまつわるシステム設計は、BtoBをやっていればいつか必ず遭遇することになる。その際にドメインに関する知識を一切持たずにまともなシステム設計をすることはたいていの場合難しい。 Web系であれなんであれ、BtoBなソフトウェアエンジニアは自分たちが取り組むドメインに関する知識を持ってシステム設計に臨む必要がある。これはデザインパターンや設計手法"以前"の話だ。 ITエンジニアのための「業務知識」がわかる本 ITエンジニアのための【業務知識
「製品開発の知識」読書メモ - Crieit
TL; DR アジャイルでやってこう！ メモ書きの割にまとまってないけど、それだけ重要な点が多いってことで許してください。 それくらいには、読んでためになる内容が多かった印象です。 はじめに 「製品開発の知識」という書籍（以降、本書と呼びます）の内容要約、および、自身の感想などを記します。 本書は、2002年に発売の古い本ですが、2016年には第15版が登場しています。 今回は、その第15版を読みました（何が違うかは把握できてませんが、多分ここかなーという目星はついた程度です）。 製品開発の知識 | 日本経済新聞出版 製品開発の知識 (日経文庫) | 延岡 健太郎 |本 | 通販 | Amazon 本書の要約については、である調で記します。 箇条書きについては、次のルールで記述しています。 簡単に書くと、項目自体についてを太字で、項目の説明を常体で、それぞれ書いていきます。 項目1 項目1
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
技術系の境界線 | La Verda Luno
これは 設計ナイト2020 の感想記事です。 CQRS と GraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、（レポートというよりも）考えたことを書き残しておきます。 発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。 コンテキスト DDD・CQRS・GraphQL・アーキテクチャの進化戦略などについて深い話（触ってみたレベルでなく実運用等を経たもの）についても興味深かったのですが、サーバー再度にとっての理想的なモデルとフロントエンドの要求が衝突する境界線について考えるきっかけになりました。もしかしてサ
デザインシステムの作り方徹底ガイド 参考にしたい導入事例まとめ
この記事では、デザインシステムを作成するときの基本ガイドをまとめています。 この記事は3つのパートで構成されています。 デザインシステムを理解する（デザインシステムとは何か、いつ作るべきか？） デザインシステムの作成（作成プロセスとやっておきたい項目） デザインシステムの具体的なサンプル例（デザイナーとデベロッパー、それぞれの観点より） デザインシステム追加の検討事項（その他のコンセプトや参考文献など） *この記事では、Webサイトやアプリ、オンラインサービスなどを表す包括的な用語として、「プロダクト（Product）」という言葉を使用しています。 この記事のコンセプトをイラスト化するために作成した、デザインシステムを公開しています。ご自由にお使いください。 Basic Design System – Figmaファイル デザインシステムを理解しよう デザインシステムとは？ デザインシステ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザインパターン[モデリング] -TECHSCORE-