会議室/wikiの横幅を広げませんか?

Last-modified: 2021-06-10 (木) 10:52:07

会議室」へ戻る

お題:wikiの横幅を広げませんか?
お名前-- 2021-05-27 (木) 12:28:12分類レイアウトジャンル提案

内容:
表でデータを乗せる際、どうしても横に長くなってしまい、自動改行されてしまうケースが目立ちます。
(例:固定アーティファクト?素材の違い)
管理人であれば、設定からレイアウトの横幅を変えることができるようなので、変更してもらうことである程度は問題を緩和できるのではないでしょうか?


  • 普段から思ってた(というかChrome拡張で自分用の幅はすでに拡張済み)ので、管理人が働いてくれるならありかなぁ
    ただ、スマホとかもあるからむやみに広げるのも危険ではあるのよね
    どのくらいを最低限にするかはまた別の話orでかい表は諦めて広げてもらうって判断は必要かも
    -- 2021-05-27 (木) 12:38:52
  • 備考欄の話にもつながる部分だと思います。書いた側としては可能な限り正確な情報を入れたくて、その上表全体の幅や一行当たりの高さのことがあるため全文はできない。その辺の葛藤の結果というのが表の見にくさなどにつながっていると思います。現状では記載の中に*1二重カッコを付けることで欄外に付記したり、表の前に一通りの説明を置いたりして対応しているようです。これは個人的な意見ですが、ソートなどができる反面行固定や列固定ができないために限界があると思っています。幅を広げて大規模な表にしたけど、その行の項目名(アイテムなど)が画面の外に来てしまったり、下にスクロールしていくとheaderが見えなくなったり。(ソート使わない時は間に疑似headerを等間隔で置いたりして対応したりします)行や列の固定ができないとなるとちょうどよい折衷案にたどり着くのはなかなか難しいです。文字サイズ下げるとつぶれたりもしますしね。試しに一度幅を広げてみましょうか?AF辺りで閲覧したときの問題点などを洗い出してみて、ア解決策のヒントを見つけてみるのもいいと思います。 -- 管理人? 2021-05-27 (木) 12:55:19
  • (議題とは違うけど)とりあえず素材は暫定対応
    可能なら、巻物部分の別表分割も検討はしたいなぁ
    実際のロジックほぼ原作よね?
    -- 2021-05-27 (木) 12:57:01
  • 横幅が広い参考WIKIです -- 2021-05-27 (木) 12:58:09
  • ちょっと極端に1920にしてみます。返事が来るか13:10まで広げておきます。 -- 管理人? 2021-05-27 (木) 13:02:36
  • 先ほどは幅の伸縮の方をいじったのでもしかしたら意味がなかったかもです。今度は基本幅を最大の1366に変えてみます。 13:20まで -- 管理人? 2021-05-27 (木) 13:14:04
  • こちらが正解だったようですね。AFで表組の崩れがない事を確認しました。 -- 管理人? 2021-05-27 (木) 13:16:03
  • 結論として「出来る」けど、「実行するしない」の議論はどうなったのでしょうか?一度トップページで意見募りますか? -- 2021-05-28 (金) 06:41:04
  • 圧倒的多数という訳ではないのが悩むところ。ただ考えようによっては半数近くの人が使いにくいと感じているということなので基本幅の変更をしてもいいかもしれない。 -- 2021-05-29 (土) 09:21:28
  • ふと気になったのが、閲覧者はスマホ(PC表示含む)とPCのどっちで見てるのか?ということ。FrontPageで「PCでの閲覧を想定(略)」とあるけれど、スマホなので拡大の手間から否定というのもあり得るかなと -- 2021-05-29 (土) 09:46:19
  • その辺を考慮してなかったね。どのみちスマホではPC表示であっても画面が小さくて表の全幅表示以前の問題の気もするけど。10インチタブレットでようやくそれなりに見れる感じだから。 -- 2021-05-29 (土) 09:51:46
  • レスポンシブなので横幅広げてもスマホは影響ありません。 -- 2021-05-29 (土) 10:05:16
  • 要は今まで幅に詰め込むために|  | |  |とされていたものがWikiの幅が広がると|     |    |     |といった感じに広くなるので、今まで一画面で見えていた範囲が収まりきらなくなる。 -- 2021-05-29 (土) 10:12:44
  • ↑幅の伸縮設定すれば問題ありません。 -- 2021-05-29 (土) 11:17:27
  • 基本幅 幅の伸縮 と二つの幅があるみたいだね 伸縮の意味はよく分からないけど。 -- 調べてきた? 2021-05-29 (土) 11:23:16
  • ↑↑↑って要は中にテキストが入ってるときのことだよね?ちょっとここのページ編集で説明した方がよさそう -- 2021-05-29 (土) 11:37:15
  • ↑↑幅の伸縮についてご参考 -- 2021-05-29 (土) 11:40:36
  • |あいうえお|かきくけこさし|すせそたちつてと|
    って表を作っても
    Wikiの幅の影響で
    あいうえ
    かきくけ
    こさし
    すせそた
    ちつてと
    みたいにセルの中で折り返される。
    現状では上の形で作って下の形に表示されている。
    それをWiki幅広げると表示画面に収まりきらなくてもちゃんと
    あいうえおかきくけこさしすせそたちつてと
    と表示される。
    ただし見ている端末の画面サイズによって同じセルが
    ・折り返されるけど1画面にある程度収まっている
    ・折り返されないからそのセルを全部見ようとすると画面を縮小しないと見えない
    1セル1行のテキストであれば問題ないけど
    長い上に複数行の文章とかだと読むために左右を行ったり来たりしなければいけなくなる ということ
    それを回避するために画面を縮小すると文字が小さくなって読みづらくなる
    なので一長一短ではある
  • というか「#nobr{{}}」で囲えば横長の表でも幅調整されずにスクロールバーが付くんじゃなかったっけ? -- 2021-05-29 (土) 11:50:44
  • これだと表の下にしかスクロールバー付かないから横長なだけの表になら対応できるけど、縦長だと手に負えない。 -- 2021-05-29 (土) 11:55:28
  • スマホならスワイプ PCなら十字キーで左右に動かせば見たいところ見える -- 2021-05-29 (土) 11:59:17
  • 編集可能テーブル/固定アーティファクト・武器? -- 2021-05-29 (土) 11:59:28
  • PCの場合一度表をクリックしてから十字キーだね。そうじゃないとWiki自体を左右に動かそうとしちゃって表は動かせない。 -- 2021-05-29 (土) 12:00:46
  • カーソルの位置が表の範囲にあれば十字キーで動かせるね。てかWiki幅変更しなくても「#nobr{{}}」で挟むだけでよくない? -- 2021-05-29 (土) 12:04:02
  • 幅が解決してもそもそも論として行列の固定が出来ない件はWikiの表の限界として見にくい原因一位なんだけどね。 -- 2021-05-29 (土) 12:09:04
  • 列幅の固定は指定すれば可能です。 -- 2021-05-29 (土) 12:16:24
  • なんの列幅? 表の列幅は合計がWiki幅超えられないから今議論してるんですけど。Wiki幅広げるか否か。 -- 2021-05-29 (土) 12:19:27
  • 何故アレクサみたいに短文イエスノー回答みたいなことしか言わないんだろう。説明も解説もない…「◯◯について**を@@すればこうなって、〇〇がどうなるので解決できます」という感じにしてもらえませんかね? -- 2021-05-29 (土) 12:33:48

閲覧者:今の幅で問題ない[56]
閲覧者:今の幅だと見にくい[43]
編集者:今の幅で問題ない[13]
編集者:今の幅だとやりにくい[4]

  • 使用端末別の聞き取りができてないアンケート一応 -- 2021-05-29 (土) 13:53:59
  • 端末別投票なんか表記が整ってない? -- 2021-05-29 (土) 13:59:27
  • tつけてソートするようにしたのがいけなかったのか「固定AFのアイコンはずせ」だとか勝手に追加されたので普通のvoteにしました。 -- 2021-05-29 (土) 14:00:41
  • 編集されると元も子もないけどtvoteなら一応cookieで同一項目への重複投票を防げるので念のため設置して見たけど、民度を信じるか予防するべきかの葛藤の結果です。 -- 2021-05-29 (土) 14:03:28
  • 現状維持でいいと思います。必要ないという声も多いし発案者も最初に投下しただけっぽいし、管理者引っ張り出しておいて思い付きで自分好みに変えたかっただけってことになるよ。Wikiでそれはまずい。 -- 2021-05-29 (土) 16:01:27
  • どうしても表組のデザインを維持したい場合に「#nobr{{}}」で挟んで対応してもおk、ってことでいいんじゃない?構わなければページテンプレートに追加して終了。 -- 2021-05-29 (土) 16:04:04
  • nobrだとPC表示の場合、表の下にしかスクロールバーが付かないので、縦に長い表でかなり利便性が落ちます。(十字キーで動かせるのは初めて知りましたが…)
    問題ないという声が意外と多かったですが、どちらでもよいではなく明確に反対だという理由はあるでしょうか? -- 発案者? 2021-05-29 (土) 17:11:53
  • 既に出ているものとしてはスマホからPC表示で閲覧するとスクロールが大変になる問題があるでしょうか。
    レスポンシブ対応なのでスマホ表示でも問題ないと思っていたのですが、この場合は(PC以上に)表が改行されすぎて見づらいですね。かといってnobrは上の問題が… -- 発案者? 2021-05-29 (土) 17:46:38
  • どちらでもいいと思ってる人はいるだろうけど、ここではその意見出てた?単純に多数決で現状維持にしつつ表自体が致命的に細抹茶うやつはnobr使ってもよくすれば問題解決じゃないかね?誰かの意見を取れば誰かの意見を却下せざるを得ない訳だから、この場合投票者の意見を捨てることに問題がある気がする。妥協案というか抜け道まで用意したのに「少数意見を切り捨てるな」みたいに言ってると多重次元構造したWiki作らなければいけなくなっちゃうよ。 -- 2021-05-29 (土) 18:01:13
  • 明確に反対というのもそういった事情から「個人の意見」でしかないから強く言わないんじゃないかな? -- 2021-05-29 (土) 18:02:18
  • 問題点の洗い出し、改善策の検討、実行した場合の影響 ※ここまでのことを考えながら
    意見の集約、結果に合わせて改善策の修正、強硬策か妥協案か、
    で今出てきてるのがnobrで代用でどうですかって段階。 -- 2021-05-29 (土) 18:12:12
  • 多分意地でもWiki幅を広げさせようとしてもしない。どうしたいだけでは物事は決められないから当初の目標から後退することだってあるさ。 -- 2021-05-29 (土) 18:14:31
  • 議論はゴリ押しと絶対阻止のぶつかり合いなのではなく、現状と実行した場合の比較やリスクなどから検討し、譲歩案と妥協案で行います。そもそもの提案がとるに足らない提案ならただ却下ですけど、今は却下だけど「#nobr{{}}」という妥協案を提示したところですね。それで譲歩しないなら、よりいい案を提示するか廃案または代案が出てくるまで保留にするしかありません。 -- 2021-05-29 (土) 18:29:48
  • あー、すいません。問題点をもう少し洗い出したかっただけで、投票を無視するつもりではありません。ただ、現在の投票選択肢だとどちらでもよいと反対が区別できないのであのような聞き方になってしまいました。 -- 発案者? 2021-05-29 (土) 18:53:26
  • nobrの妥協案ですが、上記の問題点から反対です。縦に短い表でうまく使い分けるならいいですが、冒頭の例に挙げたような表なら現状維持の方がましです。 -- 発案者? 2021-05-29 (土) 18:53:43
  • もう一つの妥協案として基本幅はそのままで、幅の伸縮を変えるという手もあるようですがどうでしょうか?こちらのスマホのPC表示で見た感じでは現状と変わらず、PCのブラウザのサイズを一定以上にした場合だけ横に伸びるのでそれぞれの閲覧者でちょうどいい感じに表示されると思います。 -- 発案者? 2021-05-29 (土) 18:53:54
  • 初日に管理人さんがそれもやってくれてたようですけど見てない感じですか? -- 2021-05-29 (土) 19:00:21
  • どちらかというと否決の流れなので妥協する立場なのは変えなくていいと思ってる側では? 譲歩じゃないということは歩み寄りではないのでこの流れではしつこく食い下がってる空気読めてない人になっちゃうよ。 -- 2021-05-29 (土) 21:17:52
  • それはさておきどうしても譲れなくて次の提案てのは分かりましたが、もはや雀の涙の爪痕残しのような印象を感じます。デフォルトと伸縮変えた時の違いをもう少し分かりやすくおしえてください。判断材料がない=このままでも特に困っていない流れでは見当もできないですね。 -- 2021-05-29 (土) 21:23:33
  • 検討 -- 2021-05-29 (土) 21:25:26
  • 「#nobr{{ }}」で挟むことと各項目やテキストセル内で長文にしないように適度に「&br;」を挟んでいく。これで必要最小幅に収めつつ、どうしてもWiki幅を超えざるを得ない表でも全部入り、尚且つ事前に改行させておくことで横幅の長いセルを減らして予防しておくこともできると思います。最初のアンケートでも今のアンケートでも幅は問題ないと答えている人が結構いるのは、表組を作る人間が完成後ノミバエや制限とのバランスを取って工夫してやるものだという前提でいるからでしょう。ここが落としどころだと思いますけどいかがですか? -- 管理人? 2021-05-29 (土) 23:05:51

PC閲覧者:今の幅だと見にくい[31]
PC閲覧者:今の幅で問題ない[16]
スマホ閲覧者:今の幅だと見にくい[20]
スマホ閲覧者:今の幅で問題ない[54]
PC編集者:今の幅で問題ない[6]
PC編集者:今の幅だとやりにくい[2]
スマホ編集者:今の幅で問題ない[7]
スマホ編集者:今の幅だとやりにくい[2]

  • 提案者が妥協する気がなく譲歩案として出されたものを蹴るならこの話は終了 駄々こねても世の中思い通りにはならない -- 2021-05-31 (月) 04:25:41
  • 了解しました。今の幅のままでなんとかやりくりしたいと思います。 -- 2021-05-31 (月) 10:16:25
  • 1コメ以来静観してたけど、結局広げないほうになったのねー
    まぁ最初にも行ったけど、スマホとか考えると広い表で調整したからと言って見やすくならないから、
    スマホ閲覧者が多いなら作るときはそれを意識しないとなのよね
    意識したうえで「自分だけ」見やすくするにはChromeなら「Stylus」って拡張がおすすめ
    .container-wrapper { min-width: 930px; max-width: 1400px; }
    こんな感じ -- 2021-05-31 (月) 10:36:05
  • 編集確認ではOFFして全体の様子見つつ、閲覧時はONにしてる -- 2021-05-31 (月) 10:37:01
  • ただ打ち切りというか保留ですかね。全体のデザインに関わりしいては視認性に関わるので、目的は表の見にくさならひょおうの方で何とかできないのか、それでも無理な場合に局所的に対応できないのか(nobrですね)、それでもダメならWiki幅なのか伸縮なのか。で幅や伸縮の違いと効果を具体的に明示してプレゼンしてみてください。基本とnobrと幅変更と伸縮変更。それぞれの違いを明文化してから議論の再開を。「じゃあこっち」「これは嫌」て言ってると今までと変わりません。より良くするために使えそうなものがあるとしたら判断材料も用意してください。 -- 2021-06-01 (火) 13:23:12

*1 hogehoge