Azure Boards’ta Markdown Düzenleyici Neden Daha Sakin Oldu?
Bak şimdi, Geçen hafta bir müşteride, Azure Boards içindeki uzun açıklamaları okurken istemeden edit moduna düşme meselesi yüzünden ekip bayağı sinirlenmişti. Hani “sadece bakacaktım” diyorsun, bir anda alan düzenlenmeye başlıyor… iş akışı da orada çat diye kırılıyor. İşte Microsoft’un son dokunuşu tam bu can sıkıcı noktaya el atıyor.
İşin aslı şu ki, Markdown desteği work item alanlarına geldiğinden beri güzel şeyler öldü. Kullanım tarafında ufak bir sürtünme vardı. Ben AZ-104 ve AZ-305 hazırlıkları sırasında bile kendi notlarımı Azure Boards’a benzer yapılarda tuttuğum için bu tip küçük kullanıcı deneyimi detaylarının ne kadar önemli olduğunu çok net gördüm. Kağıt üstünde minik bir fark gibi dürüyor; pratikte işe insanın gününü değiştiriyor.
Durun, bir saniye.
Asıl problem neydi?
İlginç olan şu ki, Markdown editör ilk çıktığında amaç belliydi: büyük metin alanlarında daha okunur. Düzenli içerik sunmak. Fena fikir değildi, hatta bayağı işe yarar bir adım öldü. Ama kullanıcıların çoğu aynı şeyi söyledi: Okumak isterken yanlışlıkla düzenleme moduna girmek gereksiz yere dikkat dağıtıyordu.
Mesela de çift tıklama gibi alışkanlıklarla edit moda geçmek, bazı senaryolarda “niye şimdi yazmaya başladı bu alan?” hissi veriyordu (şaşırtıcı ama gerçek). Bir de düşünün, denetim yapan biri ya da proje yöneticisi sadece gereksinimleri kontrol ediyor; yanlış dokunuşla içerik değişmeye başlıyor. Küçük startup’ta belki tolere edilir ama enterprise tarafta bu iş ciddi bir güven ve izlenebilirlik konusu oluyor.
Bu tür arayüz sorunları bazen teknik borç gibi görünmez ama ekiplerin günlük ritmini bozar. Benim sahada gördüğüm şey şu: İnsanlar sistemi değil, sürprizi sevmiyor.
2019’da İstanbul’daki bir finans kurumunda buna benzer bir durum yaşamıştık. Doküman ekranı çok “zeki” davranıyordu; kullanıcı nereye tıklasa farklı mod açılıyordu. Sonuç? Destek talebi yağdı. O zaman da şunu anlamıştım: Kullanıcıya azıcık fazla akıllı davranan arayüz, bazen en pahalı hataya dönüşüyor.
Neler değişti?
Yeni yaklaşım oldukça net: Varsayılan olarak alanlar preview modunda açılıyor. Yanı önce rahatça okuyorsun, inceleyebiliyorsun, kontrol ediyorsun. Düzenlemek istiyorsan da üstteki edit ikonuna basıp bilinçli şekilde edit moda geçiyorsun. Bu kadar basit… ve açık konuşayım, çoğu zaman iyi tasarım zaten budur.
Hmm, bunu nasıl anlatsamdı…
Bu değişiklik bana hep otomobildeki manuel vites hissini hatırlatıyor. İstersen aracı sürersin ama geri vitese kendiliğinden geçmez; karar sende olur. Burada da mantık aynı: Okuma ile yazma ayrılmış durumda. Az önce X dedim ama aslında Y daha doğru olabilir; burada esas kazanım hız değil, kontrol.
Bir de çıkış kısmı var tabiî. Düzenlemeyi bitirince tekrar — ki bu tartışılır — preview moda dönmek kolaylaşıyor (inanın bana). Yanı ekran artık “ben seni sürekli editör sanmıyorum” diyor resmen (ve doğrusu da bu). Kâğıt üzerinde küçük görünse de günlük kullanımda bayağı rahatlatıcı. Daha fazla bilgi için Diff Satırlarını Hızlandırmak: Büyük PR’larda Sınır Nerede? yazımıza bakabilirsiniz.
Küçük ekipte etkisi
Küçük startup’larda genelde herkes her şeyi hızlıca halletmek ister. Orada bile bu güncelleme iş görüyor çünkü kimse vakit kaybetmeden not okumak istiyor; yanlışlıkla düzenlemeye girip sonra geri çıkmak kimsenin hoşuna gitmiyor. Bu konuyla ilgili Visual Studio’da Copilot Mart 2026: Ajan Devrimi yazımıza da göz atmanızı tavsiye ederim.
Hani, Bana göre küçük ekiplerde en büyük fayda şu olacak: Yeni gelen biri ekrana baktığında neyin okunur neyin düzenlenebilir olduğunu hemen anlıyor. Bu konuyla ilgili Entra External ID’de Sosyal Giriş: Native Auth GA Öldü yazımıza da göz atmanızı tavsiye ederim.
Büyük organizasyonda etkisi
Bak şimdi, Enterprise tarafta işe mesele biraz daha sertleşiyor. Onay süreçleri, denetim kayıtları, görev açıklamaları… hepsi tek yerde dönüyor ve en ufak yanlış etkileşim bile kafa karıştırabiliyor.
Logosoft’ta geçen sene bir telekom müşterisinde bunu test ederken gördük; kullanıcılar özellikle uzun incident açıklamalarını incelerken istem dışı değişikliklerden rahatsız oluyordu.
| Senaryo | Eski Davranış | Yeni Davranış |
|---|---|---|
| Kullanıcı sadece okumak istiyor | Edit moduna yanlışlıkla girme riski var | Preview mode ile daha güvenli okuma |
| Düzenleme yapmak istiyor | Bazen nerede başladığı belli olmuyor | Edit ikonu ile açık ve net geçiş |
| Ekip inceleme yapıyor | Sürpriz etkileşimler can sıkıyor | Daha öngörülebilir deneyim sağlıyor |
| Büyük kurum kullanımı | Daha fazla hata ihtimali var | Daha kontrollü akış veriyor |
Neden bu kadar önemli?
Neyse uzatmayalım; burada ana mesele sadece UX değil, güven hissi de var (evet, doğru duydunuz). Kullanıcı aracı her açtığında neyle karşılaşacağını biliyorsa sisteme olan güven artıyor.
Bu çok klasik gibi durabilir. Sahada klasik olan şeyler genelde en değerlisidir.
Doğrusu, Ben Azure DevOps danışmanlığı yaptığım projelerde hep şunu söylerim: “İyi araç = az sürpriz.” Mesela de DevOps kültüründe akışın kesilmemesi lazım.
Copilot ya da başka AI destekli araçlarda da aynı dersi gördük; otomasyon güzel ama nerede devreye girdiği anlaşılmalı. OpenAI Neden Bir Medya Şirketi Satın Aldı: TBPN yazımızda bu konuya da değinmiştik.
- Daha az yanlış tıklama riski
- Daha net okuma/düzenleme ayrımı
- Daha az destek talebi
- Daha yüksek kullanıcı memnuniyeti
- Daha temiz iş takibi
- Ekip içinde daha tutarlı kullanım
Açık konuşayım, bu tarz iyileştirmeler bazen manşete çıkmaz. Ama ürünü her gün kullanan kişi için etkisi büyüktür. Hatta bazı projelerde tam tersine “küçük” görünen düzeltmeler asıl farkı yaratır — özellikle yoğun operasyon ortamlarında.
Sahada bunu nasıl değerlendiririm?
Eğer sız de Azure Boards’u yoğun kullanıyorsanız benim önerim şu olur:
önce rollout’un tamamlanmasını bekleyin. Birkaç kritik work item türünde deneyin.
Mesela epic açıklamaları, security bug kayıtları ya da müşteri eskalasyon notları… Bunlar uzun olur ve sürprizi sevmez.
Bence burada Microsoft doğru yönde gidiyor (bizzat test ettim). Hâlâ ufak cilalar gerekebilir.
Mesela erişilebilirlik tarafında ikonların anlamı ilk bakışta yeterince net mi,
mobilde nasıl hissettiriyor,
klavye kısayolları yeterince sezgisel mi…
bunlar henüz tamamen pişmiş değil gibi geliyor bana. Bu konuyla ilgili GPT-5.1 Codex Modelleri Emekli Öldü: Ne Yapmalısınız? yazımıza da göz atmanızı tavsiye ederim.
{
"previewMode": true,
"editModeTrigger": "explicit icon click",
"userGoal": [
"read content safely",
"edit only when intended",
"exit back to preview"
]
}
Nerede çok işe yarar?
Eh, Süreç odaklı ekiplerde fena değil.
Mesela release notlarıyla bağlı çalışma yapan takımlarda iş görüyor çünkü herkes aynı sayfaya bakarken yanlışlıkla içerik oynanmıyor.
Nerede yetmeyebilir?
Eğer takımınız aşırı hızlı içerik üretip tüketiyorsa ve herkes sürekli metin üzerinde çalışıyorsa,
bir iki ek kısayol beklenebilir.
Yanı çözüm iyi ama sihirli değnek değil.
Kendi gözümden kısa değerlendirme
2024’ün sonunda bir kamu projesinde markdown tabanlı not yapısını yeniden tasarlarken benzer tartışmalar yaşamıştık.
Orada ekipten biri demişti ki:
“Okumayı kolaylaştıran şey aslında yazmayı da koruyor.”
O cümle kulağa basit geliyor ama bence olayın özeti o.
Microsoft’un yaptığı değişiklik tam olarak bunu yapıyor. Kullanıcının niyetini merkeze koyuyor. Edit modu artık gizlice gelmiyor; çağrılmayı bekliyor — Böyle düşününce insana biraz tuhaf geliyor. İyi anlamda tuhaf…
Sıkça Sorulan Sorular
Azure DevOps Markdown editör nedir?
Azure DevOps içindeki büyük metin alanlarını Markdown ile biçimlendirmeye yarayan düzenleyicidir.Preview ve edit akışıyla hem okumayı hem yazmayı destekler.
Yeni preview mode neyi değiştiriyor?
Varsayılan açılışı preview hâle getiriyor.Böylece kullanıcı önce içeriği okuyor, düzenleme için ayrıca edit ikonuna basıyor.
Bu güncelleme neden önemli?
Yanlışlıkla düzenlemeyi azaltıyor ve arayüzü daha öngörülebilir yapıyor.Bu da özellikle yoğun kullanılan work item ekranlarında rahatlık sağlıyor.
Herkese hemen geldi mi?
Microsoft önce sınırlı müşteride test edip sonra yaygınlaştırdı.Yani rollout aşamalı ilerledi.
Kaynaklar ve İleri Okuma
Azure DevOps Blog — Improving the Markdown Editör for Work Items
Microsoft Learn — Azure Boards Work Item Form Controls
Microsoft Learn — Azure DevOps Agile Process Guidance
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
3 comments